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.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to