Bug 160 - GLSL extension to support D3D floating point rules
: GLSL extension to support D3D floating point rules
Status: CLOSED WONTFIX
Product: AMD Catalyst™Proprietary Display Driver
Classification: Unclassified
Component: OpenGL Driver
: .archived
: All Linux
: low normal
Assigned To: nobody
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-12 04:45 CDT by machete
Modified: 2013-01-05 02:08 CST (History)
3 users (show)



Attachments
Water not working (Bel'Shir Beach) (406.43 KB, image/jpeg)
2011-06-26 14:08 CDT, machete
Details
Other Shaders not working (812.05 KB, image/jpeg)
2011-06-26 14:09 CDT, machete
Details
Settings (631.03 KB, image/jpeg)
2011-06-26 14:10 CDT, machete
Details

Note You need to log in before you can comment on or make changes to this bug.
Description machete 2011-06-12 04:45:23 CDT
Hi,
I would like to draw your attention to another StarCraft II issue which breaks ingame shaders: [URL="http://bugs.winehq.org/show_bug.cgi?id=26967"]Bug 26967[/URL].
Would it be possible to implement the suggestion mentioned there?
Comment 1 pierre.boudier@amd.com 2011-06-12 11:25:46 CDT
I looked at the bug report, and I am not sure what you are asking.

is it about 0.0*inf ? which class of GPU ?
Comment 2 machete 2011-06-13 06:59:15 CDT
The problem is that D3D doesn't seem to be following the IEEE floating point rules in which case 0.0*Inf is 0.0 and not NaN. In older versions wine did not follow the IEEE rules and therefore returned 0.0 but since patch db8d681a5b088b3b0dd58c6952086891f6bbb4f5 this is not the case any more and 0.0*Inf returns NaN which breaks shaders in games which actually assume 0.0*Inf is 0.0
In the wine bugtracker people said that it would be only possible to fix this if the driver vendors would write an extension.
Unfortunately I am not a wine developer and do not have the knowledge to help specificaly with this matter but I wanted to draw your attention to this issuey.
Another quite intresting comment could be this one: http://bugs.winehq.org/show_bug.cgi?id=23906#c30
Comment 3 pierre.boudier@amd.com 2011-06-13 09:17:19 CDT
http://msdn.microsoft.com/en-us/library/cc308050(v=vs.85).aspx

"
Honored IEEE-754 Rules

Some of these rules are a single option where IEEE-754 offers choices.

Divide by 0 produces +/- INF, except 0/0 which results in NaN.
log of (+/-) 0 produces -INF. log of a negative value (other than -0) produces NaN.
Reciprocal square root (rsq) or square root (sqrt) of a negative number produces NaN. The exception is -0; sqrt(-0) produces -0, and rsq(-0) produces -INF.
INF - INF = NaN
(+/-)INF / (+/-)INF = NaN
(+/-)INF * 0 = NaN
NaN (any OP) any-value = NaN
The comparisons EQ, GT, GE, LT, and LE, when either or both operands is NaN returns FALSE.
Comparisons ignore the sign of 0 (so +0 equals -0).
The comparison NE, when either or both operands is NaN returns TRUE.
Comparisons of any non-NaN value against +/- INF return the correct result.
"

so our recent GPU should behave as the above, and others won't. 

unfortunately, we can't change this behavior for older GPU, which is why I was asking for which GPU was involved. (if that is a recent one, it would be a bug)
Comment 4 amigo_zhen 2011-06-14 02:03:44 CDT
Could you provide a shader so that we can reproduce it and report this issue to SC?
Comment 5 machete 2011-06-15 05:30:29 CDT
@amigo_zhen
I am not quite shure what you mean by that, do you actually mean a programmed shader or the shaders inside sc2, which are broken? In SC2 water shaders are affected, the map Bel'Shir Beach for example has a lot of water.

@pierre.boudier@amd.com
Yes but the problem is that SC2 does not follow these roles, you quoted that (+/-)Inf * 0.0 = NaN but as far as the wine developers have backtraced it, sc2 wants (+/-) Inf * 0.0 = 0
Comment 6 machete 2011-06-15 05:31:28 CDT
(In reply to comment #5)
> @amigo_zhen
> I am not quite shure what you mean by that, do you actually mean a programmed
> shader or the shaders inside sc2, which are broken? In SC2 water shaders are
> affected, the map Bel'Shir Beach for example has a lot of water.
> 
> @pierre.boudier@amd.com
> Yes but the problem is that SC2 does not follow these roles, you quoted that
> (+/-)Inf * 0.0 = NaN but as far as the wine developers have backtraced it, sc2
> wants (+/-) Inf * 0.0 = 0

I am sorry, i meant these rules ;)
Comment 7 amigo_zhen 2011-06-21 04:07:26 CDT
Everything runs well. We cannot duplicate this bug here: Ubuntu10.10 x64 + Wine + SC2 (Ultra GPU settings, Ultra Shaders settings, Algria Valley or any others maps). 

Could you upload any screenshots of your settings or errores?
Comment 8 machete 2011-06-21 09:47:34 CDT
Did you use wine stable (1.2.x) or the unstable one (1.3.x). The water bug appears only with a recent version of wine (1.3.22). I will post screenshots later unfortunately I am not home right now
Comment 9 machete 2011-06-26 14:08:57 CDT
Created attachment 163 [details]
Water not working (Bel'Shir Beach)

I am sorry for the delay - had a lot of stuff to do.

Screenshot is done with wine 1.3.22 on an ATI Radeon 4900 HD
Comment 10 machete 2011-06-26 14:09:38 CDT
Created attachment 164 [details]
Other Shaders not working
Comment 11 machete 2011-06-26 14:10:01 CDT
Created attachment 165 [details]
Settings
Comment 12 Henri Verbeet 2011-08-09 13:18:19 CDT
(In reply to comment #3)
> http://msdn.microsoft.com/en-us/library/cc308050(v=vs.85).aspx
> 
> "
> Honored IEEE-754 Rules
> 
...
> 
> so our recent GPU should behave as the above, and others won't. 
> 
> unfortunately, we can't change this behavior for older GPU, which is why I was
> asking for which GPU was involved. (if that is a recent one, it would be a bug)

Hi, I'm one of the wined3d developers. I only saw this bug now, otherwise I would have replied here earlier. The issue is the following:

D3D10 does indeed follow IEEE rules, but D3D9 doesn't. Unfortunately some applications depend on the D3D9 behavior, in particular for multiplications with 0. They break if +/-INF * 0.0 returns NaN. It would be impractical to try to work around this in Wine.

An extension to fix this would allow GLSL shaders to explicitly specify which behavior they want, for example through an #pragma. Allowing a shader to switch between MUL / MUL_IEEE opcodes for multiplies, DOT / DOT_IEEE for dot products, etc. Note that we actually need both behaviors in wined3d, one for d3d9 and earlier, the other for d3d10 and later.
Comment 13 Michael Cronenworth 2011-11-17 18:37:07 CST
This message is a reminder that your bug is marked as Catalyst 11.5.

The current Catalyst version is 11.11.

Approximately 7 days from now the Bugzilla administrator will be removing the
11.5 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla
administrator provides this as a unofficial, free service to AMD customers, and
I like to keep my systems neat and tidy. If you would like to keep your bug
from being closed, please try a new Catalyst version and update the 'version'
field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will
change it for you.
Comment 14 Michael Cronenworth 2011-11-24 13:15:01 CST
This bug is being closed due to the 'version' being 11.5 after 7 days of the
previous closure notice.

Thank you for your bug report.
Comment 15 pierre.boudier@amd.com 2012-03-16 10:22:32 CDT
I think that this issue still is relevant.
Comment 16 Michael Cronenworth 2012-11-27 21:35:56 CST
This message is a reminder that your bug is marked as Catalyst 12.2.

The current Catalyst version is 12.10. A beta driver (12.11) is also available.

Approximately 7 days from now the Bugzilla administrator will be removing the
12.2 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla
administrator provides this as a unofficial, free service to AMD customers, and
I like to keep my systems neat and tidy. If you would like to keep your bug
from being closed, please try a new Catalyst version and update the 'version'
field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will
change it for you.
Comment 17 Michael Cronenworth 2013-01-05 02:07:33 CST
This bug is being closed due to the 'version' being 12.2 after 30+ days of the
previous closure notice.

Thank you for your bug report.

(Oops. Time got away with me.)