-----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@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.