<div dir="ltr"><div>I meant Wine games and games ported from DX9 to GL, and all GL games designed for DX9-level hardware.</div><div><br></div><div>I suggest you simply ignore what the specs are saying. GL was a mess at that time and didn't match what the hardware was capable of. GL and extensions started being reasonably defined for hardware with GL 3.0 / DX10-level functionality.</div><div><br></div><div>Marek<br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 4:57 AM Erik Faye-Lund <<a href="mailto:erik.faye-lund@collabora.com">erik.faye-lund@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2018-11-20 at 10:08 +0100, Erik Faye-Lund wrote:<br>
> On Tue, 2018-11-20 at 01:21 -0500, Marek Olšák wrote:<br>
> > I'd like to keep ARB_texture_float enabled on drivers that don't<br>
> > support linear interpolation. ARB_texture_float is required by DX9,<br>
> > which doesn't require linear interpolation.<br>
> <br>
> This logic sounds circular. Since ARB_texture_float *does* require<br>
> linear interpolation, are you sure DX9 requires ARB_texture_float?<br>
> How<br>
> would DirectX even require a GL extension?<br>
> <br>
> Are you talking about Gallium Nine or something like that? If so, it<br>
> should probably require some combination of OES_texture_half_float<br>
> and<br>
> OES_texture_float instead, no?<br>
> <br>
> FWIW, I can't find any refreences to ARB_texture_float in Gallium<br>
> Nine...<br>
> <br>
> What exactly are you talking about?<br>
> <br>
<br>
OK, I think perhaps I've figured it out; you're probably referring to<br>
Wine's emulation. And the problem is that OES_texture_half_float /<br>
OES_texture_float are only available (outside of mesa) from OpenGL ES.<br>
A state-tracker has enough information, but not an application.<br>
<br>
It looks a bit to me like there's simply no OpenGL extension that<br>
matches the DX9 behavior. I find this surprising, because ATI had a<br>
bunch of floating-point texturing demos for Radeon 9600 etc. Even<br>
ATI_texture_float doesn't seem to diallow filtering either...<br>
<br>
This also brings up another problem. We expose ATI_texture_float if<br>
ARB_texture_float is supported. But this seems like a bad choice;<br>
ATI_texture_float defines a *different* 16-bit floating point format<br>
than ARB_texture_float. From the ATI_texture_float spec:<br>
<br>
"There are no NAN or infinity values for 16 bit floating-point."<br>
<br>
However, the ARB_texture_float-extension defines both NAN and infinity<br>
values...<br>
<br>
Especially NAN-propagation has been problematic with cross-API<br>
emulation in the past.<br>
<br>
Since the ATI_texture_float and ARB_texture_float enums have the same<br>
values, I doubt there's little to do here apart from either accepting<br>
this problem, or stop advertising ATI_texture_float (which probably<br>
leads to problems with old applications that doesn't care about NAN /<br>
infinity)...<br>
<br>
But perhaps we should at least document problems like these somewhere?<br>
<br>
</blockquote></div></div></div>