>Haswell should be the minimum platform for full acceleration...

Why? Acceleration works here even on Ivy Bridge as far as I can see:
~8.5 seconds in Chrome 59, Chrome 60, Chrome 62.
i7 3770k, Windows 7, GTX750Ti, 2560x1600 full screen (F11 key)
Note, the test duration depends on window size.

Apparently something else is causing the problem you observe.
Please post the contents of chrome://version and attach the output from chrome://gpu
Also, make sure to run the benchmark without any browser extensions.
Usually an incognito window will do the job, or a new browser profile.

Haswell is the minimum for hardware rasterization (Intel GPU-wise).

Just put Version 60 back on with a clean profile.

It sounds like they did something to break it on Intel GPUs since you're getting good performance with your GeForce.

Deleted: gpu.htm 103 KB

gpu.htm 103 KB View Download

Deleted: About Version.html 5.2 KB

About Version.html 5.2 KB View Download

Well?  Anyone have an idea?

The chrome://gpu between 59 and 60 look identical, so there's nothing there to indicate why chalkboard runs twice as slow.

...unless Chromium is trying to deprecate old hardware for no reason.

Tried testing the issue on 3 different windows machines by navigating to URL: https://testdrive-archive.azurewebsites.net/performance/chalkboard/ and running the benchmark. The observations in all the 3 machines with respective processor description is as follows:
1. Win-7 desktop having processor as Intel(R) Core(TM) i7-4770 CPU @3.40Ghz(8 CPUs), ~3.4GHz, chrome 60.0.3112.78 score was showed as 12.05 for the first time, when it was ran the 2nd time it showed as 11.99. Hence, this seems to be very inconsistent.
2. Win-10 Laptop having processor as Intel(R) Core(TM) i7-4712HQ CPU @2.30Ghz(8 CPUs), ~2.3GHz, both chrome 60.0.3112.78 and chrome 59.0.3071.115 score was shown >= 40 sec.
3. Win-10 desktop having processor as Intel(R) Core(TM) i7-4770 CPU @3.40Ghz(8 CPUs), ~3.4GHz, both chrome 60.0.3112.78 and chrome 59.0.3071.115 score was showed as 10.10.

Note: Same behaviour is observed with Chromium developer builds #62.0.3175.0, latest stable #60.0.3112.78 and chromium version #59.0.3071.115. The score is 10.** in all the 3 builds as mentioned above.

This issue seems to be related to Haswell processor and laptop with that particular processor seems to be unavailable with TE-India. Hence, adding label TE-NeedsTriageFromMTV for further investigation.

Thanks...!!

The issue seems to be GPU blacklisting or maybe something else. Changing component.

We haven't done anything in SVG land to make this kind of thing change, and our perf monitoring would probably have told us if we did.

krajshree - 

The only thing I see with the 2nd Windows 10 test is that your CPU is clocked much lower than the other two tests.

So I enabled TurboBoost on my CPU and disabled Speedstep.  I forced my clock to 3.0ghz-3.7ghz.

The result was that in both 59 and 60, the clock speed is around 3GHZ while running the test.

One thing you do not mention in your results is your GPU driver version, or whether you're using the iGPU on your tests or a discrete GPU.  Your second test is with a mobile Intel chip, but your first and third tests are with desktop chips.

To reiterate, my Intel driver is version 10.18.14.4578.

Please post more details, otherwise your tests are meaningless.  Thank you.

Victor, would you be able to triage this further?

A couple of things:

When I stated earlier that an increase in clock speed was attempted, I forgot to add that it didn't make a difference.  The only thing I saw which was a bit odd, was that with Chrome 60, Speedstep was all over the place when enabled, with the clock jumping low to high rapidly while the chalkboard test was being performed.  On 59, it was steadily high.

Second, there are a host of other tests available:
https://testdrive-archive.azurewebsites.net/

Yes, they're from Microsoft, but I believe Chromium developers should run them religiously between major version changes to avoid things like this.  If you'd like me to run a different test on 59 and 60, I'd be glad to.

For example, on 59 I get around 22 seconds for the Lite Brite test:

https://testdrive-archive.azurewebsites.net/Performance/LiteBrite/

I haven't tested with 60 on it, but the point is that these tests exercise all the features so it's a good way to check if there has been a performance regression with the addition or modification of something.

FYI, Chalkboard in IE scores about 13 seconds on this platform.  This is Windows 7 with all the latest updates installed.

I think there's a misunderstanding here.  The IE Chalkboard benchmark is slower _because_ of GPU Acceleration.

SVG path rendering is easier to achieve in software rendering on many cores, than with GPU Rasterization.  We have worked and continue to work on improving path rendering performance under GPU Rasterization.  However we have enabled GPU Rasterization on Haswell+ CPUs because it is an improvement in other render intensive cases, which we care more than synthetic benchmarks like IE Chalkboard.

Is this affecting your real world browsing experience?

Firstly and most importantly, to answer your last question...  I don't know.  I was worried about getting more dropped frames in 1080p60 HTML5 videos, so I was posting this to be in effect a canary in the coalmine, so-to-speak.  So my process was to install 60, run the test (which is what I always run), then revert back because obviously performance had degraded.  I didn't take the time to feel it out.

Also, I came across this:

"After much analysis Sunny concluded that the frame_times and mean_frame_time metrics are flawed on Windows. These metrics seem to be looking at both BenchmarkInstrumentation::ImplThreadRenderingStats and BenchmarkInstrumentation::DisplayRenderingStats trace events on this platform. In the "good" trace, the browser UI is occasionally redrawing (presumably caused by the Omnibox), and drawing *more* frames than in the "bad" trace. Other than that, the times to draw WebGL appear unchanged. So krb, your CL is *improving* things by reducing the number of frames drawn! The additional frames aren't useful, but are skewing the frame_times and mean_frame_times metrics. These metrics are apparently computed differently on different platforms -- on Android, they are tied into the SurfaceFlinger -- which is why the frame_times and mean_frame_time metrics regressed only on Windows."

https://bugs.chromium.org/p/chromium/issues/detail?id=739303#c18

Can you please explain that post in layman's terms Eric?  My bug seems to be a duplicate of that one, but in that post he's instructing the author to close it...  Why though?  If he correctly identified the underlying problem, why then label it as "wontfix"?

Thanks

Re #11, just to confirm the suspicion about the IE Chalkboard performance you can disable GPU Rasterization in chrome://flags/#enable-gpu-rasterization to see if the test runs in 8 seconds again.

This change made IE Chalkboard use GPU Rasterization on all Intel GPUs from Haswell on.
 https://chromium.googlesource.com/chromium/src/+/8e75e9c587155933fe3e775605e18111a6cc2b9c.

> I was worried about getting more dropped frames in 1080p60 HTML5 videos

The IE Chalkboard test is unlikely to be indicative of HTML5 video performance or general browsing performance.  It's a very specialized test with lots of complex animated paths.

Sir, you are a gentleman and a scholar.

I did one better to confirm what you said -- I put 60 back on with a clean profile and I disabled rasterization and the test ran well.

A couple of questions, my good man:

1)  #gpu-rasterization-msaa-sample-count is always set to 0 on my installs.  If veto to software is gone and now GPU rasterization is handling the test, why the penalty in performance on the 4600 iGPU if Haswell iGPU only suffers with MSAA enabled?  Is Chromium ignoring this setting or is it unable to alter it because the compositor inherits MSAA from Direct2D?

2)  Why was veto to software eliminated for Intel?  (Not that I'm complaining...  Force enabled should mean force enabled.  There should have been a seperate option in flags for veto to software exposed to the end user, in my opinion).

Thanks

The decision was based on two data points:

1) While raw performance on path-heavy pages (such as the Chalkboard) may go down, performance-per-watt on those pages is better: power usage is generally much lower on one GPU than on many cores. (Another way to look at this is that a single GPU is often better performing than a single CPU core would be, where power consumption is roughly comparable; see --disable-gpu-rasterization --num-raster-threads=1.)

2) It allows all pages access to GPU rasterization, so even if path rendering is slower, video, image resampling, etc drawing on the same page are all generally faster and more power-efficient.

Note both items in #14 are meant to answer #13 question 2. As to #13 question 1 (what's up with MSAA on Intel), maybe ericrk can answer that? It seems there was an MSAA-related bug that was also recently fixed which may be relevant?

Removing from bisect bucket since TE was not able to repro.

>Removing from bisect bucket since TE was not able to repro.

Seriously?  You were unable to reproduce?

Honestly, what's so difficult here?  Haswell chokes with hardware rasterization on this test.  Why?  I just tested this with a Radeon 7770...  The test flew (Resolution 1600x1200, 2008-era Yorkfield CPU, Win7).  Is this just your way of saying you're passing the buck?

Also, senorblanco, with all due respect, you don't answer the question for if the slowdown with rasterization is only with Intel and MSAA, why is there still a slowdown when MSAA is disabled via flags?

Thanks

> 1)  #gpu-rasterization-msaa-sample-count is always set to 0 on my installs.  If veto to
> software is gone and now GPU rasterization is handling the test, why the penalty in
> performance on the 4600 iGPU if Haswell iGPU only suffers with MSAA enabled?  Is Chromium
> ignoring this setting or is it unable to alter it because the compositor inherits MSAA from Direct2D?

a. Software Raster 
b. GPU Raster - No MSAA
c. GPU Raster - MSAA

On Intel Haswell the performance on this test is: a > b > c.  You are getting 'b', because we currently believe this is the best performance balance for Intel GPUs.

> Honestly, what's so difficult here?  Haswell chokes with hardware rasterization on this test.  
> Why?  I just tested this with a Radeon 7770...  The test flew (Resolution 1600x1200, 2008-era
> Yorkfield CPU, Win7).  Is this just your way of saying you're passing the buck?

I think the issue has already been explained, and you also kindly confirmed the reason in #13.  We don't need to have the TE team further review this issue.

> Also, senorblanco, with all due respect, you don't answer the question for if the slowdown
> with rasterization is only with Intel and MSAA, why is there still a slowdown when MSAA is disabled via flags?

As mentioned above, we always use mode 'b' on Intel - unless you disable GPU Raster and we use mode 'a'.


I'm closing this issue as the reported performance is in line with our expectations, and not too horrible if I might add.

Razer Blade Stealth, Win 10, Core i7-7500U, HD 620
Chrome     12.16s
Edge       23.41s
Firefox   217.22s

MacBook Pro 15-inch Mid 2015, OS X 10.12.6, Core i7-4980HQ, Iris 5200 Pro
Chrome     14.41s
Safari     47.96s
Firefox   189.15s

You have contributed nothing and have wasted everyones time by failing to read the ticket.

Now I will open a new ticket, and hopefully you won't have anything to do with it this time.

I just want to conclude with this:

I found out what the root of the problem is, and ironically, the mod who closed this ticket and changed it to "wontfix" unintentionally helped solve the mystery.

Initially, when I purchased my laptop, I specifically purchased a Haswell because chrome://gpu specifically stated that rasterization should only be enabled for "Haswell or better" for now.

That was an error on the part of the person who wrote that.  What they should have said was "Should only be enabled on Intel GT3 or better for now".

The Haswell GPU comes in two flavors:  GT2 and GT3.  "Iris" 5xxx is GT3.  Haswell's GT2 (4600) is the same as Ivy Bridge's GT2 (4000), and the Chrome is limited by the GT2's poor performance.

So this is indeed not Chromium's fault, but in fact Intel's fault.  Thanks to those who contributed to this discussion.

 Issue 756278  has been merged into this issue.

Update:

I did a little more research and came up with this:

"In comparison to the HD 4000, the graphics core has been modified extensively. The GPU supports DirectX 11.1, OpenCL 1.2 and OpenGL 4.0. It also features an improved decoder for 4K videos and the fast Quick Sync encoder."

"... the HD 4600 not only matches some dedicated GPUs such as the GeForce GT 620M/630M, but also competes with the fastest integrated AMD GPUs like the Radeon HD 8650G"

Why then does chalkboard run perfectly fine on a 630m or an 8650G but twice as slow on a HD4600?

Please re-read  vmi...@chromium.org's comment when he closed the issue...  He notes the tests done with his different hardware and then concludes that everything is perfectly fine.

Someone please explain the poor performance with HD4600.