This dEQP test fails at the following commit: Author: Connor Abbott <cwabbott0@gmail.com> AuthorDate: Sat Jun 6 13:32:21 2015 -0400 Commit: Connor Abbott <cwabbott0@gmail.com> CommitDate: Fri Oct 30 02:19:00 2015 -0400 i965: always run the post-RA scheduler Before, we would only do scheduling after register allocation if we spilled, despite the fact that the pre-RA scheduler was only supposed to be for register pressure and set the latencies of every instruction to 1. This meant that unless we spilled, which we rarely do, then we never considered instruction latencies at all, and we usually never bothered to try and hide texture fetch latency. Although a later commit removes the setting the latency to 1 part, we still want to always run the post-RA scheduler since it's able to take the false dependencies that the register allocator creates into account, and it can be more aggressive than the pre-RA scheduler since it doesn't have to worry about register pressure at all. Test master post-ra-sched diff %diff bench_OglPSBump2 396.730 402.386 5.656 +1.400% bench_OglPSBump8 244.370 247.591 3.221 +1.300% bench_OglPSPhong 241.117 242.002 0.885 +0.300% bench_OglPSPom 59.555 59.725 0.170 +0.200% bench_OglShMapPcf 86.149 102.346 16.197 +18.800% bench_OglVSTangent 388.849 395.489 6.640 +1.700% bench_trex 65.471 65.862 0.390 +0.500% bench_trexoff 69.562 70.150 0.588 +0.800% bench_heaven 25.179 25.254 0.074 +0.200% Reviewed-by: Jason Ekstrand <jasoan.ekstrand@intel.com> Sample test output: Standard Output /tmp/build_root/m64/opt/deqp/modules/gles3/deqp-gles3 --deqp-case=dEQP-GLES3.functional.shaders.discard.dynamic_loop_texture --deqp-surface-type=fbo --deqp-log-images=disable --deqp-surface-width=256 --deqp-surface-height=256 dEQP Core 2014.x (0xcafebabe) starting.. target implementation = 'DRM' Test case 'dEQP-GLES3.functional.shaders.discard.dynamic_loop_texture'.. Vertex shader compile time = 5.244000 ms Fragment shader compile time = 0.635000 ms Link time = 5.734000 ms Test case duration in microseconds = 254539 us Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%)
FYI Same commit broken UE4 SunTemple rendering, not sure if it is same issue though.
Tapani, I assume the UE4 issue is not SNB - specific. If so, can you check a few platforms and open another bug? I imagine that a multi-platform UE4 bug will have higher priority than a single dEQP test on an old platform.
> Tapani, I assume the UE4 issue is not SNB - specific. If so, can you check > a few platforms and open another bug? > > I imagine that a multi-platform UE4 bug will have higher priority than a > single dEQP test on an old platform. There's nothing SNB-specific about the actual bug and, yes, it's probably the same bug for both. Why it didn't show up in any piglit or deqp test other than this one on SNB, I have no idea. Unfortunately, it's really hard to make tests that intentionally hit scheduler bugs.
This patch: http://lists.freedesktop.org/archives/mesa-dev/2015-November/099473.html fixes this particular test but I can't really tell if it regresses anything because of GPU hangs on SNB with deqp. Since master also GPU-hangs (according to Jenkins) and I've spot-tested a bunch of the failures and they seem to pass, I think the patch is probably ok. Tapani, does it also fix sun-temple?
The SNB dEQP tests are probably because I dropped Google's dEQP blacklist and made my own. I have a task to identify the root cause and disable the offending test. Don't let SNB dEQP hangs dissuade you, if all other platforms pass.
I just pushed the patch that *should* fix this. I'm marking this bug as closed. Mark, please re-open if it's still broken (it shouldn't be). Tapani, please file a new bug if SunTemple is still broken.
SunTemple got fixed by this same patch, thanks!
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.