| Issue 527565 | Blacklist MSAA on Intel GPUs for non-WebGL content | ||||||||
| Starred by 9 users | Project Member Reported by ericrk@chromium.org, Sep 2 2015 | Back to list | |||||||
Path rendering on Intel GPUs is very poor - in some benchmarks up to 6.8x worse than SW. Even when falling back to 4x MSAA we still see major slowdowns on path heavy benchmarks (see attached image, for the chalkboard benchmark of the smoothness.tough_path_cases telemetry metric). Given this, we'd like to blacklist MSAA on Intel GPUs, causing pages which require MSAA to fall back to software rendering. This blacklist should only affect rasterized content, not WebGL. This may require a bit of extra plumbing.
Comment 1
by
ericrk@chromium.org,
Sep 2 2015
,
Sep 29 2015
Mo, are you still able to take a look at this? Otherwise I can give it a shot. Thanks!
,
Sep 30 2015
Sorry I've been overwhelmed with other stuff. Thanks for offering to take it over. Let me know if you have any questions on the implementation of this.
,
Sep 30 2015
,
Oct 1 2015
This means we won't use Ganesh when in low-power mode on macbooks which is unfortunate, also new macbooks have only Intel Iris graphics, does this blacklist apply to them too? That would mean no modern macbook would use Ganesh.
,
Oct 1 2015
No, we'll still use Ganesh. We'll just drop to software rasterization for complex path content, as we used to do on Android prior to the tessellating path renderer (veto-to-software, instead of veto-to-MSAA).
,
Oct 1 2015
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe commit ed27437d3a0a58534dd6cb877b18d2d60d1d21fe Author: ericrk <ericrk@chromium.org> Date: Thu Oct 01 22:18:54 2015 Blacklist MSAA for GPU Raster on Intel GPUs Intel GPUs have unacceptable performance for GPU raster when MSAA is enabled. This has been tested on recent Intel GPUs on CrOS, Mac, and Windows. Given this we’re adding a workaround for Intel GPUs which will disable MSAA for GPU raster. We don’t want to impact WebGL, so this workaround specifically targets non-WebGL contexts. I’ve updated FeatureInfo’s Initialize function to accept the context type, which allows us to customize features based on webgl/non-webgl. I’ve also changed the secondary version of Initialize, which takes no arguments, to be InitializeForTesting, as this function is only called in tests. BUG= 527565 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1374043005 Cr-Commit-Position: refs/heads/master@{#351904} [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/buffer_manager_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/context_group.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/context_group.h [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/feature_info.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/feature_info.h [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/feature_info_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/framebuffer_manager_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/gles2_cmd_decoder.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/query_manager_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/renderbuffer_manager_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/service/texture_manager_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/command_buffer/tests/gl_unittest.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/config/gpu_driver_bug_list_json.cc [modify] http://crrev.com/ed27437d3a0a58534dd6cb877b18d2d60d1d21fe/gpu/config/gpu_driver_bug_workaround_type.h
,
Oct 1 2015
,
Dec 21 2015
This appears to have affected `pp::Graphics3D` contexts, was that intentional? I would expect Pepper graphics contexts to be treated like WebGL contexts, but that does not appear to be the case?
,
Dec 21 2015
This is a bug. Eric, will you be able to work a fix? Basically we need to add a different context type CONTEXT_TYPE_ES2_PEPPER for pepper and exclude it from the workaround.
,
Dec 21 2015
,
Jan 6 2016
,
Mar 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d72af43d432d9def9ce591b7167c19b7b1581e30 commit d72af43d432d9def9ce591b7167c19b7b1581e30 Author: ericrk <ericrk@chromium.org> Date: Fri Mar 18 21:44:31 2016 Add CONTEXT_TYPE_OPENGLES2_PEPPER Adds a new context type for Pepper GL contexts. This allows us to fine tune driver bug workarounds for pepper vs. non-pepper contexts. Currently used to disable the Intel MSAA blacklist on pepper contexts, as it should be up to the app whether to use MSAA. BUG= 527565 CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel Review URL: https://codereview.chromium.org/1781093002 Cr-Commit-Position: refs/heads/master@{#382097} [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/cc/output/delegating_renderer.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/cc/output/gl_renderer.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/cc/test/test_web_graphics_context_3d.h [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/cc/trees/layer_tree_host_impl_unittest.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/command_buffer/common/capabilities.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/command_buffer/common/capabilities.h [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/command_buffer/service/feature_info.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/command_buffer/service/feature_info_unittest.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/command_buffer/service/gles2_cmd_decoder.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/config/gpu_driver_bug_list_json.cc [modify] https://crrev.com/d72af43d432d9def9ce591b7167c19b7b1581e30/gpu/config/gpu_driver_bug_workaround_type.h
,
Mar 21 2016
Moved to a model where we use gpu::Capabilities to disable msaa in the compositor/skia only. Should resolve existing issues.
,
Jul 8 2016
If this is fixed, shouldn't it be removed as a "Problem Detected" from chrome://gpu in ChromeOS dev 53.0.2785 ?
,
Sep 1 2016
I see how this can be a bit misleading. This issue is "fixed" in that it's mitigated by detecting the issue and working around it (hence the entry in about://gpu). As we don't plan to take further action on the issue, I closed out the bug. Hope this makes sense.
,
Oct 23 2016
Running this with default settings (rasterization in software due disabling mitigation on Intel) http://codepen.io/eltonkamami/full/ECrKd results in 35 FPS with 55+ with rasterization enabled. Maybe whitelist newer Intel Graphics? Ran on a HP Chromebook 13 G1, Core m5 - Skylake GT2, Intel Graphics 515 Version 55.0.2883.17 dev (64-bit) Would be great to have an offical benchmark to run though.
,
Oct 23 2016
Also tried MSAA 16 and forced enable on all layers for VP9 content, also 60fps. |
|||||||||
| ► Sign in to add a comment | |||||||||
