Re: [Dri-devel] tdfx and Mesa blending bug fixes

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> On Wed, Oct 18, 2000 at 08:21:52PM -0600, Brian Paul wrote:
> |
> | In Mesa, software blending was failing the Glean blendFunc test because
> | of using bit-shifts instead of integer divide.  I've fixed that.
> 
> I haven't checked, but I suspect something like
> 
>         unsigned char src = ...;
>         unsigned char srcFactor = ...;
>         unsigned char dst = ...;
>         unsigned char dstFactor = ...;
>         unsigned int pix = src * srcFactor + dst * dstFactor;
>         unsigned char result = (pix + (pix >> 8)) >> 8;
> 
> might be close enough to pass, and would avoid the performance cost of
> a full integer divide.  (I'm not positive about the math, but
> something like that expression is probably pretty close.  Boundary
> conditions still need to be checked.)

I've got some integer divide approximation code around here somewhere
I could dig up.  I think I've seen what you suggest above before and
will try it out.


> | Using the tdfx-3 driver on Voodoo5 I found and fixed a few blending
> | problems caused by mismapping of GL blend modes to Glide blend modes.
> | Interestingly, the Voodoo5 hardware appears to have some inaccuracy in
> | its blending circuits because a variety of blend modes fail in Glean
> | with errors ranging from 1.02949 to 1.16156 bits.  Not much we can do
> | about that.
> 
> At this stage it's OK, just something people should know about.  If
> lots of implementations fail, then the test is too stringent, and we
> should relax it a little.

OK.

-Brian