Re: [PATCH 1/4] wined3d: Handle fog_start == fog_end with table fog
On 14 June 2013 22:34, Stefan Dösinger <stefan(a)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(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvNhFAAoJEN0/YqbEcdMwjfEP/1nPD4/1hIZAG/YDroQpYTqQ KuoSdCxs6eq2RL8sm02e5GhuODUL9In1rsoNB26vPEMYK+Gvl/QfxufqTM92HAdU AD3E/1rS1ALAKJ276Betu6Fkkp6ZFUcKQrRgN4HEXyi0zn3Xf+5PsO3XYvgwPjln Rl9EbSuy2j2eQvH/ybbokwzZ5btb62CvhhwFEttwkZtXj44hibF72ofGCsUh/NIl 5QZSKPE2f9r/wW5KnqfYRgP7a+UrHk1wpmoAmBIZ5H3Xua2n55k7ofVeitYcRCYp 9+qh3k/Vzk7sqggos2s2cSt7gnzfgdz9o4oBetGufwMwAJ/Md8HeR7fRLojb4oru vxcfIL3Q2G7BO4yeQ2Kk1dIxR3rkCKiLh9OoN3ACDjfMvQZKvYzOnhUOVbxLzBqW Jp+AzHX2ZqqsHChjuPFF2zroBXkEz9zXyKkpz/Nbo88vqgVMg9VFSLepou6X9fUn Xw3goO/fOCe+kZ3bEKb+jhbqAvlU7qaHAm8Qs8xxMoeHTtVfWwSlN9fTm4z9wrHE dZWQ5fCGpsmuwxY6hm0MhDbyfMpV5xPdHvxFA5glX5wC4rJqdrfQMVLvImEhbl4T Qgq5ZiYojmit3jpr1MAr1h4nOyRhmdUPjCL6BEnFVp1TfSylxVA/yZtQatW65QA5 6FApdSgz+lTEilXT0cD8 =6pcA -----END PGP SIGNATURE-----
On 15 June 2013 23:10, Stefan Dösinger <stefan(a)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.
participants (2)
-
Henri Verbeet -
Stefan Dösinger