On 14 June 2013 22:34, Stefan Dösinger stefan@codeweavers.com wrote:
{float increase = eps;volatile float fogend2 = fogend;do{fogend2 += increase;increase *= 2.0f;}while (fogstart == fogend2);fogend = fogend2;}
Why is this needed? When end == start I'd expect (end - c) / (end - start) to evaluate to +/-INF, and then get clamped to [0, 1], which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend.
Am 15.06.2013 um 10:40 schrieb Henri Verbeet hverbeet@gmail.com:
Why is this needed? When end == start I'd expect (end - c) / (end - start) to evaluate to +/-INF, and then get clamped to [0, 1], which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend.
When I looked at the same problem back in 2007, the GL fixed function pipeline disabled fog when start == end. Admittedly I did not re-test that assumption. I'll have a look at it later today.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-06-15 10:40, schrieb Henri Verbeet:
Why is this needed? When end == start I'd expect (end - c) / (end
- start) to evaluate to +/-INF, and then get clamped to [0, 1],
which is pretty much what you'd want. In my (very limited) testing, that's also what actually happens with at least the GLSL backend.
I re-tested this on Nvidia and r600g. GLSL works as expected on both drivers, but ARB and the fixed function GL pipeline have different behavior. On Nvidia, everything is fogged (like d3d vertex fog). r600g seems to increase one of the parameters like my patch does, with two differences: It adds a higher number, so there's a visible fog gradient, and it increases fogstart (or decreases fogend), so it produces the opposite of what we want.
I can test other drivers, but I think it is safe to conclude that fogstart==fogend is not well defined in GL and we want to avoid it.
On 15 June 2013 23:10, Stefan Dösinger stefan@codeweavers.com wrote:
I re-tested this on Nvidia and r600g. GLSL works as expected on both drivers, but ARB and the fixed function GL pipeline have different behavior. On Nvidia, everything is fogged (like d3d vertex fog). r600g seems to increase one of the parameters like my patch does, with two differences: It adds a higher number, so there's a visible fog gradient, and it increases fogstart (or decreases fogend), so it produces the opposite of what we want.
I can test other drivers, but I think it is safe to conclude that fogstart==fogend is not well defined in GL and we want to avoid it.
Well, the spec seems pretty unambiguous. In the case of Mesa, it looks like a slightly broken optimization (http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/program/prog_statevars.c...), that could probably be fixed, especially if you also supply a piglit testcase. I wouldn't be all that surprised if something similar was happening on nvidia, although that one is of course harder to get fixed.
As far as wined3d is concerned, it seems to me that the most you can conclude is that some drivers have issues with the fixed function implementation of this. If we care enough about pre-SM2 hardware (because everything else will end up using GLSL) we could consider adding a quirk for that, but it should be limited to the fixed function / ARB program path and the affected drivers in that case.
-
Henri Verbeet -
Stefan Dösinger