Re: [Mesa-dev] XCOM: Enemy Unknown vs. NaN texture unit LOD bias

[Kenneth Graunke]

On Thursday, July 13, 2017 4:23:14 PM PDT Ian Romanick wrote:
> On 07/10/2017 11:25 PM, Kenneth Graunke wrote:
> > Hello,
> > 
> > Mesa master has been hitting assert failures when running "XCOM: Enemy
> > Unknown" since commit f8d69beed49c64f883bb8ffb28d4960306baf575, where we
> > started asserting that the SAMPLER_STATE LOD Bias value actually fits in
> > the correct number of bits.
> > 
> > Apparently, XCOM calls
> > 
> >glTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, val);
> > 
> > to set the texture unit LOD bias...but according to gdb, the value is:
> > 
> >-nan(0x73)
> > 
> > In i965, we do CLAMP(lod bias, -16, 15)...but NaN ends up failing both
> > the < min and > max comparisons, so it slips through.  But, that raises
> > the question...what value *should* we be using?  0?  Min?  Max?
> > 
> > I couldn't find any immediately applicable GL spec text.  Anyone know of
> > any?  If not, does DirectX mandate something?
> 
> There is one place.  Section 2.3.4.1 (Floating-Point Computation) of the
> OpenGL 4.5 core profile spec says:
> 
>"The result of providing a value that is not a floating-point number
>to such a command is unspecified, but must not lead to GL
>interruption or termination. In IEEE arithmetic, for example,
>providing a negative zero or a denormalized number to a GL command
>yields predictable results, while providing a NaN or an infinity
>yields unspecified results."
> 
> Crashing is not allowed, but nearly any other behavior is.  Based on
> that, I like Roland's suggestion of changing the CLAMP() macro.  We
> should also report this to the developers.  I'd wager that some crazy
> NaN value is not what they intended.

Hi Marc,

I think I may have found a bug in "XCOM: Enemy Within" - it appears to be
setting the texture unit LOD bias to -nan(0x73) via glTexEnv.  Passing
in a NaN here can cause unspecified results...meaning you likely get an
arbitrary LOD bias.  I'm guessing this isn't what you intended.

See above for the details.  I just sent patches to work around the crash
(assertion failure) in i965 due to the NaN popping up in unexpected places,
but we'll end up setting the LOD bias to -16, which I imagine could have a
performance impact...

https://lists.freedesktop.org/archives/mesa-dev/2017-July/162921.html

The bogus glTexEnv call happens immediately after the intro videos end,
and you reach the main menu (new game, load, etc).

Any thoughts?

--Ken

signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XCOM: Enemy Unknown vs. NaN texture unit LOD bias

[Ian Romanick]

On 07/10/2017 11:25 PM, Kenneth Graunke wrote:
> Hello,
> 
> Mesa master has been hitting assert failures when running "XCOM: Enemy
> Unknown" since commit f8d69beed49c64f883bb8ffb28d4960306baf575, where we
> started asserting that the SAMPLER_STATE LOD Bias value actually fits in
> the correct number of bits.
> 
> Apparently, XCOM calls
> 
>glTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, val);
> 
> to set the texture unit LOD bias...but according to gdb, the value is:
> 
>-nan(0x73)
> 
> In i965, we do CLAMP(lod bias, -16, 15)...but NaN ends up failing both
> the < min and > max comparisons, so it slips through.  But, that raises
> the question...what value *should* we be using?  0?  Min?  Max?
> 
> I couldn't find any immediately applicable GL spec text.  Anyone know of
> any?  If not, does DirectX mandate something?

There is one place.  Section 2.3.4.1 (Floating-Point Computation) of the
OpenGL 4.5 core profile spec says:

   "The result of providing a value that is not a floating-point number
   to such a command is unspecified, but must not lead to GL
   interruption or termination. In IEEE arithmetic, for example,
   providing a negative zero or a denormalized number to a GL command
   yields predictable results, while providing a NaN or an infinity
   yields unspecified results."

Crashing is not allowed, but nearly any other behavior is.  Based on
that, I like Roland's suggestion of changing the CLAMP() macro.  We
should also report this to the developers.  I'd wager that some crazy
NaN value is not what they intended.

> I wrote a hack to check isnan and replace it with 0, which gets the game
> working again, but...it seems like we could have this problem in a lot of
> other places too...and I'm not sure what the right answer is.
> 
> https://cgit.freedesktop.org/~kwg/mesa/commit/?h=xcom=6a1c0515b760c943eb547cced754b465aa3bd4ca
> 
> Thanks for any advice :)
> 
> --Ken



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XCOM: Enemy Unknown vs. NaN texture unit LOD bias

[Marek Olšák]

On Tue, Jul 11, 2017 at 3:08 PM, Roland Scheidegger  wrote:
> Am 11.07.2017 um 08:25 schrieb Kenneth Graunke:
>> Hello,
>>
>> Mesa master has been hitting assert failures when running "XCOM: Enemy
>> Unknown" since commit f8d69beed49c64f883bb8ffb28d4960306baf575, where we
>> started asserting that the SAMPLER_STATE LOD Bias value actually fits in
>> the correct number of bits.
>>
>> Apparently, XCOM calls
>>
>>glTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, val);
>>
>> to set the texture unit LOD bias...but according to gdb, the value is:
>>
>>-nan(0x73)
>>
>> In i965, we do CLAMP(lod bias, -16, 15)...but NaN ends up failing both
>> the < min and > max comparisons, so it slips through.  But, that raises
>> the question...what value *should* we be using?  0?  Min?  Max?
>>
>> I couldn't find any immediately applicable GL spec text.  Anyone know of
>> any?  If not, does DirectX mandate something?
> I would guess behavior is undefined for GL.
> I don't think d3d10 would say anything directly for this case, however
> generally when things get converted to fixed point somewhere in the gpu
> pipeline, the spec mandatates nans get converted to 0. This may or may
> not be applicable here as it isn't really converted to fixed point
> directly here.
>
> We could also just make the CLAMP macro nan-safe easily (min2/max2
> already are if you use them reversed...)
> So instead of
> #define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) :
> (X)) )
>
> use
> #define CLAMP( X, MIN, MAX ) ( (X)>(MIN) ? ((X)>(MAX) ? (MAX) : (X)) :
> MIN) )

I like this. It's certainly the cheapest way of converting NaNs to MIN.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] XCOM: Enemy Unknown vs. NaN texture unit LOD bias

[Roland Scheidegger]

Am 11.07.2017 um 08:25 schrieb Kenneth Graunke:
> Hello,
> 
> Mesa master has been hitting assert failures when running "XCOM: Enemy
> Unknown" since commit f8d69beed49c64f883bb8ffb28d4960306baf575, where we
> started asserting that the SAMPLER_STATE LOD Bias value actually fits in
> the correct number of bits.
> 
> Apparently, XCOM calls
> 
>glTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, val);
> 
> to set the texture unit LOD bias...but according to gdb, the value is:
> 
>-nan(0x73)
> 
> In i965, we do CLAMP(lod bias, -16, 15)...but NaN ends up failing both
> the < min and > max comparisons, so it slips through.  But, that raises
> the question...what value *should* we be using?  0?  Min?  Max?
> 
> I couldn't find any immediately applicable GL spec text.  Anyone know of
> any?  If not, does DirectX mandate something?
I would guess behavior is undefined for GL.
I don't think d3d10 would say anything directly for this case, however
generally when things get converted to fixed point somewhere in the gpu
pipeline, the spec mandatates nans get converted to 0. This may or may
not be applicable here as it isn't really converted to fixed point
directly here.

We could also just make the CLAMP macro nan-safe easily (min2/max2
already are if you use them reversed...)
So instead of
#define CLAMP( X, MIN, MAX )  ( (X)<(MIN) ? (MIN) : ((X)>(MAX) ? (MAX) :
(X)) )

use
#define CLAMP( X, MIN, MAX ) ( (X)>(MIN) ? ((X)>(MAX) ? (MAX) : (X)) :
MIN) )

Which would fix this elsewhere too, with no extra effort even (at least
I'd think so - on x86_64, both should probably compile to just
minss/maxss combo, and if you get a nan or not there just depends on the
order of the arguments).
(This is, of course, assuming that min/max aren't NaN, but I'd think in
most (or all?) uses of CLAMP these are constant, non-NaN values).
Though it doesn't give you zero, unless the lower bound is zero (which
is probably often the case but not here). I have of course no idea if
the app would be happy with that...

And of course that's not filtering the values as they come through the api.

Roland


> 
> I wrote a hack to check isnan and replace it with 0, which gets the game
> working again, but...it seems like we could have this problem in a lot of
> other places too...and I'm not sure what the right answer is.
> 
> https://cgit.freedesktop.org/~kwg/mesa/commit/?h=xcom=6a1c0515b760c943eb547cced754b465aa3bd4ca
> 
> Thanks for any advice :)
> 
> --Ken
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] XCOM: Enemy Unknown vs. NaN texture unit LOD bias

[Kenneth Graunke]

Hello,

Mesa master has been hitting assert failures when running "XCOM: Enemy
Unknown" since commit f8d69beed49c64f883bb8ffb28d4960306baf575, where we
started asserting that the SAMPLER_STATE LOD Bias value actually fits in
the correct number of bits.

Apparently, XCOM calls

   glTexEnv(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, val);

to set the texture unit LOD bias...but according to gdb, the value is:

   -nan(0x73)

In i965, we do CLAMP(lod bias, -16, 15)...but NaN ends up failing both
the < min and > max comparisons, so it slips through.  But, that raises
the question...what value *should* we be using?  0?  Min?  Max?

I couldn't find any immediately applicable GL spec text.  Anyone know of
any?  If not, does DirectX mandate something?

I wrote a hack to check isnan and replace it with 0, which gets the game
working again, but...it seems like we could have this problem in a lot of
other places too...and I'm not sure what the right answer is.

https://cgit.freedesktop.org/~kwg/mesa/commit/?h=xcom=6a1c0515b760c943eb547cced754b465aa3bd4ca

Thanks for any advice :)

--Ken

signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev