Bug 89293 - [i965] [bisected] [VMware Workstation] 514fd1c commit breaks some Piglit tests in Windows VMs
Summary: [i965] [bisected] [VMware Workstation] 514fd1c commit breaks some Piglit test...
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.4
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jason Ekstrand
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-24 07:14 UTC by Svyatoslav Pankratov
Modified: 2015-02-26 21:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Additional files for resolving issue (1.55 MB, application/octet-stream)
2015-02-25 10:16 UTC, Svyatoslav Pankratov
Details

Description Svyatoslav Pankratov 2015-02-24 07:14:46 UTC
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.
Comment 1 Jason Ekstrand 2015-02-24 18:24:03 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 ***
Comment 2 Jason Ekstrand 2015-02-24 18:53:30 UTC
(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?
Comment 3 Svyatoslav Pankratov 2015-02-25 10:16:41 UTC
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.
Comment 4 Jason Ekstrand 2015-02-26 21:51:03 UTC
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.