System Environment: -------------------------- Platform: BDW/BSW Libdrm: (master)libdrm-2.4.58-19-gf99522e678dbbaffeca9462a8edcbe900574dc12 Mesa: (master)ff9653775962ab661c4891721b1b93d077d1f2db Xserver: (master)xorg-server-1.16.99.901-85-g91651e7c15892aa846fc406fbb13b37f094dd3f0 Xf86_video_intel:(master)2.99.916-172-g04a09d353fc5ad8a55eb2457dc8bb43638ba879e Libva: (master)cdfd3d50d80c092ca3ae8914418be628d5a80832 Libva_intel_driver:(master)f2a34f94c57e1f7ce975b2068fb087df84b92e3a Kernel: (drm-intel-nightly)a243fbbcfd348ec042b100f3ce02f215252d177d Bug detailed description: --------------------------- It fails on BDW/BSW with mesa master branch, works well on 10.4 branch. Following cases also fail with same bisect commit: spec_ARB_shader_atomic_counters_semantics spec_ARB_shader_atomic_counters_unique-id spec_ARB_shader_atomic_counters_unused-result spec_glsl-1.10_execution_varying-packing_simple_float_array spec_glsl-1.10_execution_varying-packing_simple_float_separate spec_glsl-1.10_execution_varying-packing_simple_mat2x3_array spec_glsl-1.10_execution_varying-packing_simple_mat2x3_separate spec_glsl-1.10_execution_varying-packing_simple_mat2x4_array spec_glsl-1.10_execution_varying-packing_simple_mat2x4_separate spec_glsl-1.10_execution_varying-packing_simple_mat2_array spec_glsl-1.10_execution_varying-packing_simple_mat2_separate spec_glsl-1.10_execution_varying-packing_simple_mat3x2_array spec_glsl-1.10_execution_varying-packing_simple_mat3x2_separate spec_glsl-1.10_execution_varying-packing_simple_mat3x4_array spec_glsl-1.10_execution_varying-packing_simple_mat3x4_separate spec_glsl-1.10_execution_varying-packing_simple_mat3_array spec_glsl-1.10_execution_varying-packing_simple_mat3_separate spec_glsl-1.10_execution_varying-packing_simple_mat4x2_array spec_glsl-1.10_execution_varying-packing_simple_mat4x2_separate spec_glsl-1.10_execution_varying-packing_simple_mat4x3_array spec_glsl-1.10_execution_varying-packing_simple_mat4x3_separate spec_glsl-1.10_execution_varying-packing_simple_mat4_array spec_glsl-1.10_execution_varying-packing_simple_mat4_separate spec_glsl-1.10_execution_varying-packing_simple_vec2_array spec_glsl-1.10_execution_varying-packing_simple_vec2_separate spec_glsl-1.10_execution_varying-packing_simple_vec3_array spec_glsl-1.10_execution_varying-packing_simple_vec3_separate spec_glsl-1.10_execution_varying-packing_simple_vec4_array spec_glsl-1.10_execution_varying-packing_simple_vec4_separate Bisect shows:ee5fb8d1ba7f50ed94e1a34fa0f6e15a0588145e is the first bad commit commit ee5fb8d1ba7f50ed94e1a34fa0f6e15a0588145e Author: Kristian Høgsberg <krh@bitplanet.net> AuthorDate: Mon Oct 20 23:29:41 2014 -0700 Commit: Kristian Høgsberg <krh@bitplanet.net> CommitDate: Wed Dec 10 12:29:27 2014 -0800 i965: Generate vs code using scalar backend for BDW+ With everything in place, we can now use the scalar backend compiler for vertex shaders on BDW+. We make scalar vertex shaders the default on BDW+ but add a new vec4vs debug option to force the vec4 backend. No piglit regressions. Performance impact is minimal, I see a ~1.5 improvement on the T-Rex GLBenchmark case, but in general it's in the noise. Some of our internal synthetic, vs bounded benchmarks show great improvement, 20%-40% in some cases, but real-world cases are mostly unaffected. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> output: libGL: OpenDriver: trying /opt/X11R7/lib/dri/i965_dri.so PIGLIT: {"subtest": {"Fragment atomic counter array access" : "pass"}} Probe color at (0,0) Expected: 8 4 9 5 Observed: 4070953469 2794010626 4290510838 4185915327 PIGLIT: {"subtest": {"Vertex atomic counter array access" : "fail"}} PIGLIT: {"result": "fail" } Reproduce steps: ------------------------- 1. xinit 2. bin/arb_shader_atomic_counters-array-indexing -auto -fbo
ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_vert fails on BSW due to the same bisect commit. Test run totals: Passed: 0/1 (0.00%) Failed: 1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%)
Kristian, can you reproduce this?
Just to confirm the failure is intermittent for me. How about you? bwidawsk@gibson ~/intel-gfx/piglit (master)$ while [ 1 ] ; do ./bin/arb_shader_atomic_counters-array-indexing -auto -fbo | grep Vertex -A1 |tail -n1 ; done 2>/dev/null PIGLIT: {"result": "pass" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "pass" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "pass" } PIGLIT: {"result": "pass" } PIGLIT: {"result": "fail" } PIGLIT: {"result": "pass" }
Oh, hmm.. that's only with a patch I added locally, nvm
Created attachment 113516 [details] [review] VS does the enables differently than ps Please test
(In reply to Ben Widawsky from comment #5) > Created attachment 113516 [details] [review] [review] > VS does the enables differently than ps > > Please test Fixed by this patch.
(In reply to Ben Widawsky from comment #5) > Created attachment 113516 [details] [review] [review] > VS does the enables differently than ps > > Please test Hey, nice catch, Ben! I didn't spot this when I was looking at it a while ago. Using the CE register makes a lot of sense. A couple of suggestions on the patch: 1. Could you put a /* HSW+ */ comment after the #define BRW_ARF_CE 0x40? 2. Could we put the MESA_SHADER_VERTEX case before the uses_kill case, just to keep the two pixel shader cases together? 3. I think vstride should be 0, not 4...I honestly have no idea why brw_ip_reg is the way it is, but it's been that way forever. We should probably also drop the NOTE! and ? comments. Assuming the vstride change actually works, and you're good with those suggestions, feel free to put my R-b on it.
Hey Ken. I dropped the CE register parts because on further inspection, I don't think it's useful (it's just duplicating the internal execution mask). Anyway, thanks for looking at it, hopefully the version I just pushed is at least as good as this one :-) lu hua, The patch is pushed. Closing bug.
Verified.Fixed.
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.