Summary: | [BXT/GLK] up to 6% performance drop with "i965: Set "Subslice Hashing Mode" to 16x16 on Apollolake" | ||
---|---|---|---|
Product: | Mesa | Reporter: | Eero Tamminen <eero.t.tamminen> |
Component: | Drivers/DRI/i965 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Status: | RESOLVED MOVED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | Bastha.oleng |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Eero Tamminen
2017-08-17 12:35:44 UTC
I.e. it seems that things depending on raw sampler throughput have perf drops, and everything that is completely memory bandwidth bound improves a bit. If latter gets verified by bisection, I'm not sure whether anything should be done about this bug, as bandwidth limitations should be more common for real-world use-cases than being purely sampler limited. Both FurMark and GiMark use anisotropic filtering, but I think changing hash mode for a draw, based on sampling mode, would have too much overhead. Terrain tessellation doesn't use costly filtering, so for a drop in that I don't have yet a good explanation. It's possible that using larger (16x16) area for the cross-slice load balancing checkerboard works worse for very small triangles, but impact "should" then be visible both in instancing & tessellation shader terrain tests, as both run about same amount of pixel shader instances, look same and have identical pixel shaders. Maybe different vertex order explain that difference. Bisect verified that the memory bandwidth improvements on 18 EU BXT: - 5% GLB 2.7 Fill, SynMark ZBuffer, GpuTest Triangle (fullscreen) - 3% SynMark TexMem* & TexFilterTri were also from the same Hashing Mode change that caused the perf drops. When investigating the Fill case with performance counters, 16x16 hashing mode improves the cache hit rate as expected, which explains the performance improvement. -> Marking as wontfix, the perf regressions from the commit are acceptable compromise compared to improvements. If there are important use-cases with huge amounts of really small triangles where 16x16 can regress performance, it may make sense to have this as DRI conf option for the context creation. (If terrain tessellation perf dropping, but geom instancing not with 16x16 mode is because of their different triangle ordering, that raises a question why tessellation in GPU side produces triangle order that's aligned worse for the 16x16 hashing mode.) There was also following perf drops during the same time frame, which I assume are due to same change: - 2% GpuTest v0.7 PixMark Piano - 1% GpuTest v0.7 PixMark Volplosion And now that bug 102258 is fixed, SynMark Anisotropic filtering test performance is still 6-7% lower than it was before that bug. Except for terrain tessellation tests, all the dropping test-cases use anisotropic filter. So, I think both cases that have a lot of really small triangles, and/or where usage of anisotropic filtering has clear impact for the performance, suffer from this change. Bug 102258 may have hidden also other impacts of this change, so it makes sense to re-test the impact of the hash mode on 18 EU BXT where it's more visible. The affected test-cases were: - GLB 2.7 Fill* - GpuTest v0.7 GiMark, FurMark, Piano, Volplosion & Triangle* - SynMark v7 TerrainPanTess, TerrainFlyTess, TexFilterAniso, TexFilterTri*, TexMem128, TexMem512* & ZBuffer* Potentially also Unigine Valley 1.0. (*) These were improved, others regressed with 8x8 -> 16x16 change. Looking at GKL data, Valley dropped by ~1.3% on the day of this commit, but GLB 2.7 Fill improvement was even larger than on BXT. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1618. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.