[Dri-devel] To round or not to round? Was: Mesa MMX blend code finished

[José F. <j_r...@ya...>]

On 2002.04.12 19:20 Allen Akin wrote:
> ...  It might be related to deep color channels, or possibly
> to glean tests other than the basic blending tests.  ...

That was it. I'm really sorry for all the fuzz, I just remembered I'm 
probably the last one on earth using 16bit depth! Of course the errors 
would never reach 3-4 LSB to be noticed...
> 
> Thanks for all your good work, by the way!

You're welcome!
> 
> Allen
> 

I've made the tests again and here are the differences with and without 
rounding:

32c32
< GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA 0 0
---
> GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA 0 0.917705

Both pass of course! This means that we don't need that extra precision 
from rounding.

But there is still one caveat, the results obtained wihout rounding also 
don't obey the 255x255 = 255 rule as t = 255*255, (t + (t >> 8)) >> 8 is 
254...

Making a check for a=255 in the MMX code will have its negative impact 
(especially because the MMX instruction set lack of opcodes for doing 
that).

Brian, what do you think is best?
  a) Leave everything as it is with exact results from blending (note 
that, e.g., this is a waste of time when blending to a 16bit framebuffer)
  b) Remove the rounding, and make no check for a=255 (don't know if 
OpenGL spec allows for that)
  c) I try a little harder(*) and implement a check for a=255 (note that 
this could also be beneficial if this happens frequently)

(*) harder means that due to the fact that two pixels are being blended at 
the same time I probably would have to make 4 versions of the inner loop, 
plus the duplication before&after do to the alignenment... thinking again 
I think that option c) would be very hard to be viable as the processor 
cycles taken to make these decisions would be enough to make the 
multiplication anyway, specially with the recent CPUs that have several 
pipelines...

José Fosneca