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 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
