Re: [PATCH 2/5] wined3d: Handle fog_start==fog_end with table fog(try 2)
On 17 June 2013 22:53, Stefan Dösinger <stefan(a)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. 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.
+ if (isnan(fogstart) || isinf(fogstart) || isinf(-fogstart)) You should only need one isinf() here, it's not supposed to care about the sign.
#define WINED3D_ADAPTER_CAP_XYZRHW 0x00000001 #define WINED3D_ADAPTER_CAP_VS_CLIPPING 0x00000002 +#define WINED3D_ADAPTER_CAP_BROKEN_FOG 0x00000008 Is this intentional?
On 18 June 2013 09:12, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 17 June 2013 22:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
+ if (isnan(fogstart) || isinf(fogstart) || isinf(-fogstart)) You should only need one isinf() here, it's not supposed to care about the sign. And actually, the isnan() should never happen either, because NAN != NAN.
-----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(a)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-----
On 18 June 2013 14:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Am 2013-06-18 09:12, schrieb Henri Verbeet:
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.
That's not really what I meant. Unless you explicitly disable the GLSL backend and create an unsupported configuration, r200 should be the only one of the above where you'll see the driver bug without the quirk. (And that one is only supported by Mesa anyway, so there should be no reason to not just fix the driver instead.)
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.
Sure, up to a point. Obvious bug fixes are clearly worth it, but I think workarounds for driver bugs in unsupported configurations are harder to justify.
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.
Yeah, we probably don't want that. I think the value of the ARB program backend is limited, but it's main target should be pre-SM2 hardware that can't do GLSL. (And potentially still has dedicated fog hardware.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-06-18 12:53, schrieb Henri Verbeet:
(And that one is only supported by Mesa anyway, so there should be no reason to not just fix the driver instead.) Well, in theory. In practice I'd need the register documentation. I had a very quick look at the mesa code, and it isn't as simple as removing something like "if (start == end) annoy_wine();". There's a register flag R200_FOG_TABLE that may or may not provide what d3d wants.
Supposedly the register documentation of r200 is available, but Google doesn't find it.
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.
Yeah, we probably don't want that. I think the value of the ARB program backend is limited, but it's main target should be pre-SM2 hardware that can't do GLSL. (And potentially still has dedicated fog hardware.) Since I'm still maintaining the ARB code, I prefer something like the attached patch over failing tests any time. (It's not quite done yet. The patch needs splitting, the quirk test should test an ARB shader and I'll probably limit the custom code to start == end cases.)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwE4GAAoJEN0/YqbEcdMwweMP/3IZhKiTeaVnhmVg1nfHBpjG hegDyIfFKVa1Xy2yxV3fYiKhYxuXHzHRl7pQ8qJlNLttoq2i/MMYZuQcZ9Ww3xWd sHs/UD+RTQgGasNxYYx1Ody/yjHt+fx+98rXSR2b31/oyjmzijnLZqmSr/8JSB3/ JYSNkKSW91GG/IAlcp2C4QZZo+upg4t29+WPHn4aeQeYX/oxlY6rQFVrlWwb7UBN FQL9WV29ah8Wb3jeGp5UZM0Z8C83cu5efRH5kyGsdM/8YcPzqHAoHuFv3vmnpJxi dze41y0RqgZMsocFog/VlegZqCheH1alDEmRuEkl1/1jIBGgHnJsw2FggjJ+veEg zkGmt9GXPjn2u0+gcj48a2FDpLZw5UAdwaI5jKyoDVsTY/cSk8RdoxlqcQVcu6BI xWx1XaAyjPwg81mvVyugyR0B+GSIsfXXhYl1kCExwLXuFam4Vn0RkPbwcdj1WHem g3ufGT9FHGeftCmnXMLR9ETSiHdgnB6/oabwe7fc5zLBAGfgi8fTYB4DZvXpqWas ZWAcunRRpDuIA4w7xqjYFqWNF8J6WIouki1sUrCvd/lNtBXM9ieRHgG28qY8h9JO 9xeC7UCh950juECgocTYz3W1qqsrEL9fmmbVp0HdltiBtqmTBfFSxuDtfWIN7ViZ 9HsSdt/Bw0tiXy3uRvlN =8SHq -----END PGP SIGNATURE-----
participants (2)
-
Henri Verbeet -
Stefan Dösinger