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. 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@gmail.com wrote:
On 17 June 2013 22:53, Stefan Dösinger stefan@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@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.
On 18 June 2013 14:19, Stefan Dösinger stefan@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.)
-
Henri Verbeet -
Stefan Dösinger