Bug 96907 - piglit.spec.arb_gpu_shader5.arb_gpu_shader5-emitstreamvertex_nodraw intermittent
Summary: piglit.spec.arb_gpu_shader5.arb_gpu_shader5-emitstreamvertex_nodraw intermittent
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords: bisected
: 91301 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-07-12 19:59 UTC by Mark Janes
Modified: 2019-09-25 18:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Janes 2016-07-12 19:59:47 UTC
This test fails intermittently with the following signature:

/tmp/build_root/m64/lib/piglit/bin/arb_gpu_shader5-emitstreamvertex_nodraw -auto -fbo
piglit: debug: Requested an OpenGL 3.2 Core Context, and received a matching 3.3 context

Probe color at (50,50)
  Expected: 0.000000 0.000000 0.000000
  Observed: 1.000000 0.000000 0.000000


Bisected to:
commit df31c1850d14729e27513ae733110a668f6b6e95
Author: Kenneth Graunke <kenneth@whitecape.org>
i965/gs: Use new NIR intrinsics.

By performing the vertex counting in NIR, we're able to elide a
ton of useless safety checks around every EmitVertex() call:

total instructions in shared programs: 3952 -> 3720 (-5.87%)
instructions in affected programs:     3491 -> 3259 (-6.65%)
helped:                                11
HURT:                                  0

Improves performance in Gl32GSCloth by 0.671742% +/-
0.142202% (n=621) on Haswell GT3e at 1024x768.

This should also make it easier to implement Broadwell's "Static
Vertex Count" feature someday.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Comment 1 Mark Janes 2016-07-12 20:08:12 UTC
Ken, please verify my bisection before spending too much time on this.  It was difficult and time consuming to reproduce.  I was able to trigger the test failure by running the test in a loop, while simultaneously running a full piglit suite in another window.  Here are the ways I invoked the two workloads:

for ((;;)) do /tmp/build_root/m64/lib/piglit/bin/arb_gpu_shader5-emitstreamvertex_nodraw -auto -fbo; done

and 

piglit run -o -p gbm --exclude-tests timestamp-get --exclude-tests glsl-routing --exclude-tests ext_timer_query --exclude-tests arb_timer_query --exclude-tests spec.khr_debug.object-label_gl --exclude-tests arb_framebuffer_no_attachments.arb_framebuffer_no_attachments-atomic --exclude-tests vs-float-main-return --config /home/jenkins/workspace/Leeroy/piglit-test//ivb.conf --exclude-tests glsl-1.10.execution.vs-vec2-main-return --exclude-tests spec.egl.1.4.eglquerysurface.egl --exclude-tests spec.egl.ext.client.extensions.conformance --exclude-tests spec.egl.khr.create.context --exclude-tests spec.egl.khr.get.all.proc.addresses --exclude-tests spec.egl.khr.surfaceless.context --exclude-tests spec.egl.mesa.configless.context --exclude-tests spec.egl.nok.swap.region --exclude-tests spec.egl.nok.texture.from.pixmap.basic --exclude-tests spec.egl.1.4.eglterminate.then.unbind.context --exclude-tests spec.egl.chromium.sync.control.conformance --exclude-tests arb.shader.image.load.store.execution.coherency-extra --exclude-tests arb.separate.shader.objects.validateprogrampipeline --exclude-tests glsl-1.50.execution.geometry.clip-distance --exclude-tests glsl-1.50.execution.gs-redeclares-pervertex-out-only --exclude-tests glsl-1.50.execution.redeclare-pervertex-subset-vs-to-gs --exclude-tests glsl-1.50.transform-feedback-type-and-size --exclude-tests arb.sync.clientwaitsync-timeout --exclude-tests arb.compute.shader.zero-dispatch-size -c gpu /tmp/build_root/m64/test/ivbgt2


In my tests, the looping test generally failed while the first few hundred tests in the piglit suite were executing.  Occasionally, I would have to restart the piglit suite to produce the failure.  Also, the looping test failed around test 4000 more than once.

I spent several iterations confirming that the looping test failed at the bisected revision, and I could never make it fail on the previous revision.

This failure mode has been seen on IVBGT2 and BXT.
Comment 2 Mark Janes 2016-07-12 20:12:53 UTC
*** Bug 91301 has been marked as a duplicate of this bug. ***
Comment 3 Kenneth Graunke 2016-07-13 05:25:17 UTC
I think your bisect is correct.
Comment 4 Mark Janes 2017-01-30 23:47:50 UTC
This is confirmed to be a regression for Mesa 17.
Comment 5 Mark Janes 2017-02-05 08:01:24 UTC
This bug shipped with mesa 11.1, so it is not a regression for later releases.
Comment 6 GitLab Migration User 2019-09-25 18:57:13 UTC
-- 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/1528.


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.