[PATCH 2/5] wined3d: Handle fog_start==fog_end with table fog(try 2)

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2013-06-18 09:12, schrieb Henri Verbeet:
> On 17 June 2013 22:53, Stefan Dösinger <stefan at codeweavers.com>
> wrote:
>> correctly with fixed function fog. Tested as usual on Geforce9
>> (OSX, Linux), Geforce7 (Linux), r300g, r600g, i965 (OSX), r200.
> Which of those is affected by the quirk? I think all of those
> except r200 should be able to do GLSL, but you say r200 is the only
> one that doesn't pass the tests.
All Linux drivers. The OSX drivers I tested get the special case right.

I don't know what exactly goes wrong on r200. My plan was to look at
this (why the quirk is needed in the first place, and why it doesn't
work) once more important Wine 1.6 business is done. The quirk works
with mfcfog.exe, but my tests behave as if start = 0.0 and end = 1.0,
no matter what values I set. Either there's some precision problem, or
a different state breaks the driver.

(That said, r200 has another regression documented in bug 21708 that I
have to look at.)

> You may be able to convince me that this is a good idea, but so far
> I don't think it's worth all the extra code.
My motivation is to make the tests pass on as many configurations as
possible.

I can deal with ARB in another way, by implementing the fog equation
myself instead of using #option ARB_fog_linear. That would throw
pre-sm2 hardware under the bus though.

GLSL is also lucky in the situation where fog_coord == start && start
== end. In that case the linear fog evaluates to NaN, but clamp(NaN,
0.0, 1.0) is 0.0, which afaics matches the spec. I don't know if that
is lucky wording of min() and max() or intentional. (Windows drivers
disagree if they should use the fragment color or fog color in that
case, but no windows driver uses a different color like black or pink)

>> #define WINED3D_ADAPTER_CAP_XYZRHW              0x00000001 
>> #define WINED3D_ADAPTER_CAP_VS_CLIPPING         0x00000002 
>> +#define WINED3D_ADAPTER_CAP_BROKEN_FOG          0x00000008
> Is this intentional?
No, good catch.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRwFBFAAoJEN0/YqbEcdMwhHoP/2rcw/hv5X9JJKqasYYeVUJd
uQJETFicWlnZ+BZ218VNxxFMVmaNlEkeDB7P6deimC5I+9LTbXIVOjPdVloLR7eF
HuiB+hk7PocZMYm/PXAc1I2OzDmbbErKWs2Tq+gvkUnWccioZArLFODrUopOzzMy
5aoaFXp4unMQ0ZzYGYPZD8fHKDV6MBYIjhU24gO85MaNQi/3zD/OGWzfalthAEG2
/yzUOR4GdOkF09i39ORqaQdL30XYqXSPVKdjoN8CgKwx1D87dvGOrj7351/LObcW
YwkBtFKz/d0huSBOX5wgNyAevUqc7PRA3fD69tbQ4yEW/fIg5Q6fftAOWapLPKFc
n1AYXUUouuK3iK52I/LvQM8QbQeqjdyJcmh0ld8domyMrmH7fQrCS9QyLi6baNLM
wPrRiHWRQJWOJ8gZgMhw5BcYbBGH8qn41i+UCecyK07gEHhWii9bNaC4H1rlzdgb
Q8P/dZLsap67dk8YEEWCyEC658oPYiHeJkL3j9FhCrpsPCPbfVIpwkVwIqKQ0OLz
LkwO9pW9x63b1vZoncOns4JVBWHyRF99Ex+WSuMNx23Iwja++wJ8Q4Zwm6cjxgCt
AZFhE3BaF35tMIWLEpRfxdXeZNf2tJNQ++qfup1DiNVEJH36xa2pokobAQFVILCC
pTTtyZMVwnBSJKKkE77o
=iZ5n
-----END PGP SIGNATURE-----