[Mesa-dev] [PATCH] nir/spirv/glsl450: rewrite atan2 to deal with denorms / infinities

Juan A. Suarez Romero jasuarez at igalia.com
Wed Jan 18 12:43:53 UTC 2017


On Tue, 2017-01-17 at 12:00 +0100, Juan A. Suarez Romero wrote:
> On Tue, 2017-01-17 at 11:34 +0100, Juan A. Suarez Romero wrote:
> > > The above does not necessarily sum to "we shouldn't fix it" but it probably does mean it's low-priority at best and we need to be careful.
> > > 
> > > Looking a bit into the math of atan2, I'm not convinced flushing denorms to zero is actually what we want to do.  For x, I think it's valid, but as y approaches 0, you get +/- pi/2 depending on whether y positive or negative.  As both approach zero, it's undefined.  As you approach infinity, it approaches something in the interval [-pi/2, pi/2] but it depends on the direction of approach.  If you do "man atan2" you'll see this all layed out in a horrifying amount of detail (somewhere around a dozen different cases).
> > > 
> > 
> > Yes, originally I only flushed 'x'. But then also flushed 'y' to keep coherence. But didn't think about that corner case you mention. I think we can remove the flush to 0 in 'y'.
> 
> Actually, after doing a couple of tests more, I don't think we need to flush 'x' any more.
> 
> The thing is that originally I added the flush to 0 to solve a couple of cases from Vulkan CTS atan2 tests. But later I modified the code to cope with infinities, which lead a refactoring of code. I think this refactoring made the flush to 0 not required any more.
> 
> I've run the tests again getting rid of both flushes, and seems results are exactly the same as with the flush. So maybe they are not required after all.
> 

I'm sending a new version that just gets rid of denorm_{x,y}.

	J.A.



More information about the mesa-dev mailing list