https://bugs.winehq.org/show_bug.cgi?id=43948
Bug ID: 43948 Summary: d3dx9 effects - pixel shader 2.0 does not render well Product: Wine Version: 2.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs@winehq.org Reporter: havran.jan@email.cz Distribution: ArchLinux
Created attachment 59587 --> https://bugs.winehq.org/attachment.cgi?id=59587 d3dx9 effects
I have strange behaviour of effects in d3dx9 application where I have access to source code. I tried to reduce code size to the minimum where this bug is still reproduciable. The problem is, when I apply attached shaders.fx effects (VS + PS) on some objects (triangle for example), then the object is black in Wine, while in Windows or Gallium Nine it is grey.
Here is list of configuration where it works as expected (expected = how it works on native Windows): Windows 7 + D3D9 + AMD graphics Windows 7 + D3D9 + Intel graphics Linux + Wine + Gallium Nine + AMD graphics (Mesa)
Here is list of configuration where it does not work (renders black objects): Windows 7 + WineD3D + AMD graphics Windows 7 + WineD3D + Intel graphics Linux + Wine + WineD3D + AMD graphics (Mesa) Linux + Wine + WineD3D + Intel graphics (Mesa)
There are possibly two issues in attached pixel shader: 1) uninitialized IN.lightVec 2) usage of normalize() function (and possible division by zero)
But here is the strange behaviour: 1) when I set IN.lightVec red, green or blue to 0.0 (one or two of them, but not all of them, because it cause crash), then it is rendered black in Windows and in Wine as well. 2) when I set IN.lightVec.r (for example) to "IN.lightVec.r + 0.0f", then it has no effect.
From point 2 it looks like IN.lightVec default values are 0.0f, but from point
1 it looks opposite. So I have no idea what are values of uninitialized vector.
I thought that it could be related to bug #34266 [1], but: 1) created patch did not work for me 2) when I set IN.lightVec to zero, the bug disappears
I can upload simple d3d app which use these effect and also binary file (exe).
I have no D3D (and D3D shaders) deep knowledge, so maybe I something understand wrong.
I also used native d3dcompiler_43 so Wine could compile these shaders.
[1] https://bugs.winehq.org/show_bug.cgi?id=34266
https://bugs.winehq.org/show_bug.cgi?id=43948
Jan Havran havran.jan@email.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #59587|0 |1 is obsolete| |
--- Comment #1 from Jan Havran havran.jan@email.cz --- Created attachment 59588 --> https://bugs.winehq.org/attachment.cgi?id=59588 d3dx9 efects
https://bugs.winehq.org/show_bug.cgi?id=43948
--- Comment #2 from Jan Havran havran.jan@email.cz --- Created attachment 59589 --> https://bugs.winehq.org/attachment.cgi?id=59589 d3d_shader debug
Added disassembled HLSL and generated GLSL (output from WINEDEBUG=d3d_shader)
https://bugs.winehq.org/show_bug.cgi?id=43948
Jan Havran havran.jan@email.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |havran.jan@email.cz
https://bugs.winehq.org/show_bug.cgi?id=43948
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3dx9 |directx-d3d
--- Comment #3 from Matteo Bruni matteo.mystral@gmail.com --- It's not clear to me what you tested exactly, with the attached shaders you're always forcing vertex position to 0 so, if you're drawing triangles, nothing in the rest of the shader should matter.
With reasonable vertex positions or e.g. point sprites you should be able to see something on the screen. At that point I guess you get to meet our nice old friend NaN come up from normalize(IN.lightVec). That will probably cause you to draw black on Wine regardless of what you try to do to the result of normalize(). d3d9 drivers on Windows program the GPU to avoid NaNs in ps_2_0 shaders, so you get that NaN converted to 0. nine probably hacks the rsq in the pixel shader to return a large number instead of +inf so that it becomes 0 after the multiplication by 0 instead of NaN. Or maybe it's able to set the GPU similarly to the Windows drivers, I don't recall right now. Either way, you get 0 + 0.5 = gray.
On Wine there is no such trickery and NaNs are preserved (like they should be in d3d10+, but also in shader model 3 to some degree) so you get NaN + 0.5 = NaN = black. Unfortunately there is no sensible way in OpenGL to "emulate" the d3d9 behavior correctly so we could only do hacks like the rsq thing above (as we actually did years ago). The problem is that, as with most of the hacks, other applications are going to break because of that.
https://bugs.winehq.org/show_bug.cgi?id=43948
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swswine@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43948
--- Comment #4 from Jan Havran havran.jan@email.cz --- Sorry for the very long delay.
I created this issue because I found situation where Windows behaviour is different from Wine's.
If I understand it well, this behaviour is known and there is no clean way how to fix it. So since this is known bug, is there any Wiki page with listed known bugs not planned to fix? I do not known how much bugs like this one exists, but some list would be helpful.
All I found is this: https://wiki.winehq.org/Known_Issues
-
wine-bugs＠winehq.org