<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 11, 2017 at 9:32 AM, Samuel Pitoiset <span dir="ltr"><<a href="mailto:samuel.pitoiset@gmail.com" target="_blank">samuel.pitoiset@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
On 01/11/2017 05:32 PM, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Jan 11, 2017 at 4:33 PM, Erik Faye-Lund <<a href="mailto:kusmabite@gmail.com" target="_blank">kusmabite@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Jan 11, 2017 at 4:14 PM, Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 11.01.2017 13:17, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Tue, Jan 10, 2017 at 6:48 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'll be honest, I'm not a fan... Given that D3D10 has one defined<br>
behavior,<br>
D3D9 has another, and GL doesn't specify, I don't really think we should<br>
be<br>
making a global change to all drivers to do the D3D9 behavior just to fix<br>
one app.  Sure, other apps probably have the same bug, but are we going<br>
to<br>
have apps that expect the D3D10 behavior that we've now explicitly made<br>
not<br>
work?<br>
<br>
If we're going to hack around an app bug, I would really rather see it<br>
behind a driconf option rather than a global change to driver behavior.<br>
Even better, it'd be cool if we could see the app get fixed. (Yes, I know<br>
that's not likely).<br>
</blockquote>
<br>
<br>
I think we are not in a position to refuse this workaround, or put<br>
more precisely, to have a different behavior from everybody else. By<br>
"we", I mean i965, radeonsi, svga. All closed drivers use abs. Many<br>
Mesa drivers also use abs internally (r300, r600, nv30, nv50/nvc0).<br>
This is not really a workaround for a specific application, even<br>
though it's strongly motivated by that. It's a fix to align the few<br>
remaining drivers with all others.<br>
<br>
We talked with the publisher about this a very long time ago. While I<br>
don't remember the details (Nicolai?), I think they refused to fix it<br>
because radeonsi appeared to be the only driver not doing abs.<br>
</blockquote>
<br>
<br>
If I remember correctly, it wasn't so much a refusal as a lack of<br>
follow-through. They even had an option in their framework to add the<br>
abs(...) when translating shaders, but somehow didn't turn it on<br>
unconditionally for some reason...<br>
</blockquote>
<br>
VP even says so here:<br>
<a href="https://github.com/virtual-programming/specops-linux/issues/20" rel="noreferrer" target="_blank">https://github.com/virtual-pro<wbr>gramming/specops-linux/issues/<wbr>20</a><br>
<br>
They recommend against patching mesa to do abs, though.<br>
</blockquote>
<br>
We should still patch Mesa to align the behavior with closed drivers<br>
and gallium drivers like r600g and nouveau. In other words, it's too<br>
late to tell us not to patch Mesa, because r600g and nouveau have been<br>
"patched" since the beginning.<br>
<br>
We only need to decide whether we should do it in the GLSL compiler or<br>
radeonsi, i.e. whether we should exclude i965 and svga.<br>
</blockquote>
<br></div></div>
I do agree with that.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br>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.<br><br></div><div>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.<br><br></div><div>Ok, rant over.  Push it if you want.  You can even put my nakked-by on it if you'd like. :-)<br></div></div></div></div>