On Wed, Jan 11, 2017 at 9:22 PM, Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
>
>
> On 01/11/2017 07:34 PM, Erik Faye-Lund wrote:
>>
>> On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand <ja...@jlekstrand.net>
>> wrote:
>>>
>>> On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund <kusmab...@gmail.com>
>>> wrote:
>>>>
>>>>
>>>> On Wed, Jan 11, 2017 at 7:22 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Jan 11, 2017 at 7:09 PM, Jason Ekstrand <ja...@jlekstrand.net>
>>>>> wrote:
>>>>>>
>>>>>> On Wed, Jan 11, 2017 at 9:32 AM, Samuel Pitoiset
>>>>>> <samuel.pitoi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 01/11/2017 05:32 PM, Marek Olšák wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 11, 2017 at 4:33 PM, Erik Faye-Lund
>>>>>>>> <kusmab...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 11, 2017 at 4:14 PM, Nicolai Hähnle
>>>>>>>>> <nhaeh...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11.01.2017 13:17, Marek Olšák wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 10, 2017 at 6:48 PM, Jason Ekstrand
>>>>>>>>>>> <ja...@jlekstrand.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'll be honest, I'm not a fan... Given that D3D10 has one
>>>>>>>>>>>> defined
>>>>>>>>>>>> behavior,
>>>>>>>>>>>> D3D9 has another, and GL doesn't specify, I don't really think
>>>>>>>>>>>> we
>>>>>>>>>>>> should
>>>>>>>>>>>> be
>>>>>>>>>>>> making a global change to all drivers to do the D3D9 behavior
>>>>>>>>>>>> just to
>>>>>>>>>>>> fix
>>>>>>>>>>>> one app. Sure, other apps probably have the same bug, but are
>>>>>>>>>>>> we
>>>>>>>>>>>> going
>>>>>>>>>>>> to
>>>>>>>>>>>> have apps that expect the D3D10 behavior that we've now
>>>>>>>>>>>> explicitly
>>>>>>>>>>>> made
>>>>>>>>>>>> not
>>>>>>>>>>>> work?
>>>>>>>>>>>>
>>>>>>>>>>>> If we're going to hack around an app bug, I would really rather
>>>>>>>>>>>> see
>>>>>>>>>>>> it
>>>>>>>>>>>> behind a driconf option rather than a global change to driver
>>>>>>>>>>>> behavior.
>>>>>>>>>>>> Even better, it'd be cool if we could see the app get fixed.
>>>>>>>>>>>> (Yes, I
>>>>>>>>>>>> know
>>>>>>>>>>>> that's not likely).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think we are not in a position to refuse this workaround, or
>>>>>>>>>>> put
>>>>>>>>>>> more precisely, to have a different behavior from everybody else.
>>>>>>>>>>> By
>>>>>>>>>>> "we", I mean i965, radeonsi, svga. All closed drivers use abs.
>>>>>>>>>>> Many
>>>>>>>>>>> Mesa drivers also use abs internally (r300, r600, nv30,
>>>>>>>>>>> nv50/nvc0).
>>>>>>>>>>> This is not really a workaround for a specific application, even
>>>>>>>>>>> though it's strongly motivated by that. It's a fix to align the
>>>>>>>>>>> few
>>>>>>>>>>> remaining drivers with all others.
>>>>>>>>>>>
>>>>>>>>>>> We talked with the publisher about this a very long time ago.
>>>>>>>>>>> While I
>>>>>>>>>>> don't remember the details (Nicolai?), I think they refused to
>>>>>>>>>>> fix
>>>>>>>>>>> it
>>>>>>>>>>> because radeonsi appeared to be the only driver not doing abs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If I remember correctly, it wasn't so much a refusal as a lack of
>>>>>>>>>> follow-through. They even had an option in their framework to add
>>>>>>>>>> the
>>>>>>>>>> abs(...) when translating shaders, but somehow didn't turn it on
>>>>>>>>>> unconditionally for some reason...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> VP even says so here:
>>>>>>>>> https://github.com/virtual-programming/specops-linux/issues/20
>>>>>>>>>
>>>>>>>>> They recommend against patching mesa to do abs, though.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We should still patch Mesa to align the behavior with closed drivers
>>>>>>>> and gallium drivers like r600g and nouveau. In other words, it's too
>>>>>>>> late to tell us not to patch Mesa, because r600g and nouveau have
>>>>>>>> been
>>>>>>>> "patched" since the beginning.
>>>>>>>>
>>>>>>>> We only need to decide whether we should do it in the GLSL compiler
>>>>>>>> or
>>>>>>>> radeonsi, i.e. whether we should exclude i965 and svga.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I do agree with that.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I tend to disagree but I've come to the conclusion that I won't stand
>>>>>> in the
>>>>>> way either. If both of the other desktop vendors do it and we've
>>>>>> already
>>>>>> decided that no implementation we care about will have its performance
>>>>>> impacted, it seems like a valid spec-compliant thing to do. I would
>>>>>> prefer
>>>>>> it to be behind a driconf option, but if it's unconditional, oh well.
>>>>>> My
>>>>>> disagreement is mostly philosophical.
>>>>>>
>>>>>> Over the last two years of working on Vulkan, I've been fighting
>>>>>> broken
>>>>>> tests and apps left and right. Vulkan has a huge amount of area
>>>>>> where,
>>>>>> if
>>>>>> an app does something wrong, they get undefined behavior which is up
>>>>>> to
>>>>>> and
>>>>>> including program termination. And basically all apps are broken in
>>>>>> some
>>>>>> way. Fortunately, the validation layers are finally starting to catch
>>>>>> up to
>>>>>> the point where I'm noticing very few bugs that the validation layers
>>>>>> don't
>>>>>> catch and things are getting into a better state. However, I've had
>>>>>> more
>>>>>> discussions than I can count with people where I have to explain to
>>>>>> them
>>>>>> that "No, the app is broken. It needs to be fixed. It's not my job
>>>>>> to
>>>>>> make
>>>>>> it work." Once you start allowing brokenness, you can never stop
>>>>>> allowing
>>>>>> it and you paint yourself into a corner. Suddenly, you go to make a
>>>>>> change,
>>>>>> and your design decisions are not guided by the spec, they're guided
>>>>>> by
>>>>>> the
>>>>>> spec *and* all of the broken apps that you have to keep working on
>>>>>> your
>>>>>> driver because you let something through.
>>>>>>
>>>>>> In the world of GLES and OpenGL conformance, we fight the same fight.
>>>>>> When
>>>>>> people ask me how conformance is coming, I frequently answer with,
>>>>>> "We've
>>>>>> got a bunch of people fixing <insert test suite name here> so that our
>>>>>> driver passes". It's not that mesa is particularly touchy, it's that
>>>>>> a
>>>>>> good
>>>>>> chunk of the rest of the industry just hacks around everything inside
>>>>>> their
>>>>>> driver and doesn't bother to fix the tests. Sometimes the driver that
>>>>>> passes the conformance suite isn't even the one they ship. If we're
>>>>>> going
>>>>>> to have a spec and hardware vendors (or the FOSS community) are going
>>>>>> to
>>>>>> implement it and apps are going to write to it, then we all need to
>>>>>> agree on
>>>>>> what it means and play by the rules. If an app doesn't play by the
>>>>>> rules
>>>>>> and does something with undefined behavior, then it's a broken app.
>>>>>> If
>>>>>> we
>>>>>> say, "No, it's ok, you don't have to fix it. We'll just hack around
>>>>>> it"
>>>>>> we're enablers for their broken behavior and the broken behavior
>>>>>> continues.
>>>>>> In this particular case, we're dealing with a broken app. The only
>>>>>> real
>>>>>> issue is that all of the drivers that point out the issues were not
>>>>>> drivers
>>>>>> they tested on.
>>>>>>
>>>>>> Another reason why I'm not a huge fan is that there is some momentum
>>>>>> in
>>>>>> the
>>>>>> industry to make GLSL better defined with respect to NaN. I don't
>>>>>> know
>>>>>> that
>>>>>> anything will ever come of it (because it may break apps) but if
>>>>>> something
>>>>>> does, we may find ourselves having to make SQRT and RSQ NaN-correct in
>>>>>> the
>>>>>> future and, hey look, it'll break apps.
>>>>>>
>>>>>> Ok, rant over. Push it if you want. You can even put my nakked-by on
>>>>>> it if
>>>>>> you'd like. :-)
>>>>>
>>>>>
>>>>> I agree with you completely, and I find it unfortunate too that we
>>>>> have to add the workaround to GLSL or radeonsi to align its behavior
>>>>> with closed drivers.
>>>>
>>>>
>>>> Just for reference, I just tested what NVIDIA does on Windows, and
>>>> they *don't* seem to do inversesqrt(abs(x)) on my HW/driver.
>>>
>>>
>>>
>>> What about sqrt()? Do they do abs for one and not the other? Because
>>> that
>>> would be crazy but also possible.
>>
>>
>> Not for sqrt either, it seems.
>
>
> Huh? I'm sure I have seen NVIDIA doing rsq(abs()) one day. Maybe it was
> specific to that application but I don't remember the name...
Could be. But negative inputs to inversesqrt() returns NaN for me when
writing a GLSL-shader in Render Monkey.
This fragment shader produces red output:
---8<---
void main(void)
{
gl_FragColor = vec4(0.0);
float tmp = inversesqrt(-1.0);
if (tmp != tmp)
gl_FragColor.x = 1.0;
}
---8<---
And just to be sure, I've verified that passing the -1.0 through a
varying doesn't change the result, neither does negative non-constant
values.
Now I've even tested on two different NVIDIA-GPUs, with two different
driver versions, both give the same result. I even tried on Intel's
Windows drivers, same result. I'm starting to think that this issue
hasn't been diagnosed correctly.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
