[Dri-devel] Re: Mesa software blending

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

On 2002.04.03 13:07 Marcelo E. Magallon wrote:
> [are the mailing lists having hiccups? I sent something yesterday and i=
t
> didn't show up]
>=20
> >> Jos=E9 Fonseca <j_r...@ya...> writes:
>=20
>  > +#if 0
>  >  #define DIV255(X)  (((X) << 8) + (X) + 256) >> 16
>  > +#else
>  > +	    const GLint temp;
>  > +#define DIV255(X)  (temp =3D (X), ((temp << 8) + temp + 256) >> 16)
>  > +#endif
>  > +#if 0
>=20
>  This function introduces a slight error (+-1) for about half the cases.
>  This instead:
>=20
>             DIV255(X) ((X) + ((X) >> 8) + 0x80) >> 8
>=20
>  introduces a slight error (-1) for 0.2% of the cases in the input rang=
e
>  [0, 0xFE01].  It uses only 16 bits instead of 24 bits as the original.
>=20
>  If someone is insterested:
>=20
>            x/255
>          =3D x/256*256/255
>          =3D x/256 + x/(256*255)
>          =3D x/256 + x/256**2 + x/(256**2*255)
>   approx =3D x/256 + x/256**2
>          =3D (x + x/256)/256
>=20
>  and the 0x80 is needed to account for rounding up when using interger
>  arithmetic.  The error introduced by the approximation is at most
>  255/256**2 but becomes more significant when using the last expression.
>=20
>  The error introduced by this approximation occurs only on the upper
>  half of the range of interest and is well spread all over it.  Like I
>  said before, it's always -1.  The accumulated error varies between
>  unnoticeable to quite annoying.  The only way I've found to avoid the
>  error is to use a 64 kB lookup table to perform the division.  The
>  speed difference is not significant and the accumulated error shows up
>  much later.
>=20
>  Cheers,
>=20
>  Marcelo
>=20

Yes, you're right. This problem is discussed in=20
ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf and the best way to achieve the=20
exact solution with 16 bits arithmetic was found by Blinn and is to do

#define DIV255(X)  (temp =3D (X) + 256, ((temp << 8) + temp) >> 16)

There is no hit in performance to do this, so I think it should adopted=20
instead. In fact they are so similar that I didn't noticed the difference=
=20
in the formula that Mesa was using.

I attach a small test program that I had made before.

Regards,

Jos=E9 Fonseca