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 , 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
I also used native d3dcompiler_43 so Wine could compile these shaders.
What |Removed |Added
--- Comment #3 from Matteo Bruni <[hidden email]> ---
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
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 =
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.
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.