This dEQP test fails at the following commit:
Author: Connor Abbott <firstname.lastname@example.org>
AuthorDate: Sat Jun 6 13:32:21 2015 -0400
Commit: Connor Abbott <email@example.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 <firstname.lastname@example.org>
Sample test 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
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.
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.