Bug 60801 - wine d3d9 visual test (vshader_input) fails on i965 driver
Summary: wine d3d9 visual test (vshader_input) fails on i965 driver
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords: patch, regression
Depends on:
Blocks:
 
Reported: 2013-02-13 16:34 UTC by gurketsky
Modified: 2013-03-31 00:05 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Workaround for the regression. (907 bytes, patch)
2013-02-13 16:34 UTC, gurketsky
Details | Splinter Review
INTEL_DEBUG=wm log (190.55 KB, text/plain)
2013-02-17 20:56 UTC, gurketsky
Details

Description gurketsky 2013-02-13 16:34:07 UTC
Created attachment 74765 [details] [review]
Workaround for the regression.

wine's d3d9 visual test (test_vshader_input) fails with mesa git (cb6470775c0139323bf889d2df2facdbc06a2b09) and intel i5-520um (integrated graphics). This is a regression:

a087e9f27f088c4bd00b2fddb65629c83d404860 is the first bad commit
commit a087e9f27f088c4bd00b2fddb65629c83d404860
Author: Eric Anholt <eric@anholt.net>
Date:   Tue Oct 2 15:01:24 2012 -0700

    i965/fs: Reduce the interference between payload regs and virtual GRFs.
    
    Improves performance of the Lightsmark penumbra shadows scene by 15.7% +/-
    1.0% (n=15), by eliminating register spilling. (tested by smashing the list of
    scenes to have all other scenes have 0 duration -- includes additional
    rendering of scene description text that normally doesn't appear in that
    scene)
    
    v2: Allow allocation of all but g0/g1 of the payload.
    v3: Pull count_to_loop_end() out to a helper function.
    
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2, recommended v3)

:040000 040000 3935911c187970ed21314a03106b9fd37bcdeaa1 ff456b4ff26211131c64c7b2be89cd975849f615 M	src

Steps to reproduce:
1. git clone git://source.winehq.org/git/wine.git wine-git
2. cd wine-git
3. ./configure && make
4. ./wine dlls/d3d9/tests/d3d9_test.exe.so visual

Result (please ignore the rest of the failed tests):
...
visual.c:6797: Test failed: Input test: Quad 1(2crd) returned color 0x00ff0080, expected 0x00FFFF80
visual.c:6960: Test failed: Input test: Quad 1(color-texcoord) returned color 0x00ff0040, expected 0x00ff8040
visual.c:6963: Test failed: Input test: Quad 2(color-ubyte) returned color 0x004000fe, expected 0x004080ff
visual.c:6960: Test failed: Input test: Quad 1(color-texcoord) returned color 0x00ff0040, expected 0x00ff8040
visual.c:6963: Test failed: Input test: Quad 2(color-ubyte) returned color 0x004000fe, expected 0x004080ff
visual.c:6966: Test failed: Input test: Quad 3(color-color) returned color 0x00ff0040, expected 0x00ff8040
...

The problem seems to be, that in fs_visitor::setup_payload_interference reg_width is 2 an thus the payload_last_use_ip[1 / reg_width] is not set correctly. Using payload_last_use_ip[1] works fine here and the tests pass (see the attached patch).
Comment 1 Eric Anholt 2013-02-15 14:49:15 UTC
Can you grab an INTEL_DEBUG=wm dump of the failing shader without the workaround?  Those two lines of code look perfectly fine -- g2/g3 aren't used by FB_WRITE as far as I can see, so the real bug is just getting masked.
Comment 2 gurketsky 2013-02-17 20:56:14 UTC
Created attachment 75009 [details]
INTEL_DEBUG=wm log

Attached is the INTEL_DEBUG=wm log. The last shader is the one you are looking for. Just search for "Quad" and take a look at the shader above (between "trace:d3d9:d3d9_device_DrawPrimitiveUP" and "trace:d3d9:d3d9_device_EndScene". You should just ignore the rest of the lines starting with "trace:d3d9".
Comment 3 Eric Anholt 2013-03-30 07:22:29 UTC
Does it happen with INTEL_DEBUG=no16 set?
Comment 4 gurketsky 2013-03-30 11:54:58 UTC
It does not happen, when INTEL_DEBUG=no16 is set.

Though, this is fixed by commit f10f5e498008636b110d01b2613e552da7793708 .
Comment 5 Eric Anholt 2013-03-31 00:05:07 UTC
Good to hear.

We've still got some 16-wide issues on older hardware, so I was hoping this might end up being an easier testcase for the problem than those.


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.