Re: [Mesa3d-dev] Re: [Dri-devel] Mesa MMX blend code finished

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

On 2002.04.12 18:26 Allen Akin wrote:
> On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
> |
> | I've started to play with glean and I tried to check this myself, but
> it
> | seems there is no effect in the results no matter what changes I make
> in
> | mmx_blend.S. ...
> 
> The blend test only fails if an error is greater than one
> least-significant bit in the framebuffer color channels.  If I
> understood your earlier messages correctly, none of the methods you're
> investigating has more than 1 LSB error; they differ mainly in rounding
> behavior, which I'd expect to introduce errors on the order of 0.5 LSB.

Yes, in general that's true. Although doing (p*a+q*(1-a)) >> 8 can 
introduce up to 1 LSB error and worst, it doesn't obey to the rule of 
255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending code 
this special case of a=255 is always checked, but in the MMX code it 
isn't, and glean doesn't complain of that.

> So it's possible that glean is too lenient to tell the difference
> between the methods you're testing.
> 

So how come the Mesa blending code in s_blend.c has coments such as "This 
is pretty close, but Glean complains", "This is slower but satisfies 
Glean", and "This satisfies Glean and should be reasonably fast"...?

I can only understand these statments if Mesa was being compared to some 
reference implementation..

> ...
> 
> You can select the Visual number like Brian suggested, or you can
> specify a Visual filter string on the glean command line.  For casual
> testing I normally use something like this:
> 
> 	glean -r mesa --visuals "max rgb, z, s, db" -t blendFunc
> 

Ok. Thanks!

> Allen
> 

José Fonseca