Bug 92770 - [SNB, regression, dEQP] deqp-gles3.functional.shaders.discard.dynamic_loop_texture
Summary: [SNB, regression, dEQP] deqp-gles3.functional.shaders.discard.dynamic_loop_te...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Connor Abbott
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2015-11-01 20:36 UTC by Mark Janes
Modified: 2015-11-10 01:08 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Description Mark Janes 2015-11-01 20:36:03 UTC
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)


Test run totals:
  Passed:        0/1 (0.0%)
  Failed:        1/1 (100.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)
Comment 1 Tapani Pälli 2015-11-06 07:31:40 UTC
FYI Same commit broken UE4 SunTemple rendering, not sure if it is same issue though.
Comment 2 Mark Janes 2015-11-06 16:25:27 UTC
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.
Comment 3 Jason Ekstrand 2015-11-06 18:35:30 UTC
> 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.
Comment 4 Jason Ekstrand 2015-11-06 19:05:54 UTC
This patch:


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?
Comment 5 Mark Janes 2015-11-06 20:56:40 UTC
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.
Comment 6 Jason Ekstrand 2015-11-07 16:43:12 UTC
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.
Comment 7 Tapani Pälli 2015-11-09 05:35:19 UTC
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.