Summary: | [i965] [bisected] [VMware Workstation] 514fd1c commit breaks some Piglit tests in Windows VMs | ||
---|---|---|---|
Product: | Mesa | Reporter: | Svyatoslav Pankratov <svyatoslav.pankratov> |
Component: | Drivers/DRI/i965 | Assignee: | Jason Ekstrand <jason> |
Status: | RESOLVED NOTOURBUG | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | svyatoslav.pankratov |
Version: | 10.4 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Additional files for resolving issue |
Description
Svyatoslav Pankratov
2015-02-24 07:14:46 UTC
Given that they both bisect to the same commit, I'm marking this as a duplicate of 86747. Thank you very much for your comment about color attachments, that may be substantially helpful in debugging this. *** This bug has been marked as a duplicate of bug 86747 *** (In reply to Svyatoslav Pankratov from comment #0) > System Environment: > -------------------------- > OS: Ubuntu 14.04.1 (kernel 3.13.0-45-generic) > CPU: Intel Xeon E3-1285 V2 (IB) > Mesa: 10.4.0-devel (git-514fd1c55e617bb325979cbee4a89f0727c3b567) > VMware Workstation: 11.0.0 build-2281883 > VMware Player: 7.0.0 build-2281883 > VMware tools: 9.0.0 build-1541296 > > After mentioned commit, some piglit tests start fails in Windows 7 VM under > VMware Workstation(or Player). > > How to reproduce: > ------------------------- > 1) install Mesa with guilty commit. > 2) run VMware Player Windows 7 VM. > 3) run piglit tests: > spec/ARB_framebuffer_object/fbo-drawbuffers-none gl_FragColor > spec/ARB_framebuffer_object/fbo-drawbuffers-none glDrawPixels > spec/!OpenGL 1.1/drawbuffer-modes > spec/EXT_framebuffer_object/fbo-drawbuffers > > Also I'm added to fbo-drawbuffers-none test some code for saving FBO content > with various COLOR_ATTACHMENTs into TGA texture. As result, in case with > COLOR_ATTACHMENT0 all looks fine, but with other attachments I see glitches > instead red square. > > I reverted this commit and glitches gone. This commit added some > functionality for gen 7 graphics (Haswell), but also breaks tests on > previous graphics gen - Ivy Bridge. Looks like an commit added error to > shared part for 6 and 7 gens. > > Also in some cases, like replaying apitraces from VM with executing > mentioned tests, problem may appear in qapitrace UI in another manner. Can you please run with INTEL_DEBUG=fs both before and after the offending commit and provide the results? Created attachment 113812 [details] Additional files for resolving issue (In reply to Svyatoslav Pankratov from comment #0) > I reverted this commit and glitches gone. This commit added some > functionality for gen 7 graphics (Haswell), but also breaks tests on > previous graphics gen - Ivy Bridge. Looks like an commit added error to > shared part for 6 and 7 gens. Sorry, both Ivy Bridge and Haswell are gen7 graphics. Also - problem reproducible on HSW in addition to IVB (In reply to Jason Ekstrand from comment #2) > Can you please run with INTEL_DEBUG=fs both before and after the offending > commit and provide the results? I attached archive that contains: / |- debug_514fd1c.log - stderr for guilty commit |- debug_1dd9b90.log - stderr for latest good commit |- vm.trace - apitrace |- good_texture.png - picture of good COLOR_ATTACHMENT |- bad_texture.png - picture of bad COLOR_ATTACHMENT For reproducing: > INTEL_DEBUG=fs glretrace vm.trace -s 0 -D 6737 1> result.json 2>debug.log where 6737 - call with argumentative images Also you may extract COLOR_ATTACHMENTs textures from trace and make sure that these textures are broken. The offending fragment shader in the attached apitrace has the following GLSL source: > #version 150 > #extension GL_ARB_shader_bit_encoding : enable > #extension GL_ARB_texture_query_levels : enable > vec4 O[1]; > uniform uint enableGammaDecodes; > void shader_fn(ivec2 aL); > out vec4 fragColor0; > layout(pixel_center_integer) in vec4 gl_FragCoord; > #define CONVERTOUTPUT0(v) (v) > > void main(){ > shader_fn(ivec2(0)); > fragColor0 =CONVERTOUTPUT0(O[0]); > } > > void shader_fn(ivec2 aL) { > O[0] = vec4(1, 0, 0, 1); > } As you can see, this only writes to the first color attachment, not all 4. If you don't write to one of the color attachments, you get undefined values which is exactly what you're getting. The only reason why this worked before the change was that, due to a fluke in the way the compiler was implemented, the color from the first write was getting propagated to the other 3. I don't know what the code looked like before going through VMWare's shader translator so it could be a bug there. However, we are doing the right thing. |
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.