On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote: | ... 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.
If the expected value is 255 and the OpenGL implementation yields 254, that's only one LSB of error, so glean probably won't complain about it. We could make the test more stringent, but then some reasonable implementations (especially some hardware implementations) would fail. Also, maintaining enough accuracy to yield results correct to 1 LSB is already pretty challenging when color channels are deeper than 8 bits. | 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 don't know. It might be related to deep color channels, or possibly to glean tests other than the basic blending tests. Brian might remember. Thanks for all your good work, by the way! Allen _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
