"José Fonseca" wrote: > On 2002.04.12 20:14 Brian Paul wrote: > > ... > > > > I'd like to see Mesa satisfy the 255*255=255 identity. Is it hard to > > implement that in the MMX code? If it is, we could let it go for now > > and see if anyone complains. > > I guess you didn't received my previous email yet. This is already > satisfied by the MMX code, which (as is is now) give _always_ the exact > results, including in these extreme cases, for 8 bit.
Great! > So I guess it's probably best to leave the code as it is now... but wait! > > And what if we do: > > t/255 ~= (t + (t>>8) + (t>> 15)) >> 8 > > this gives 255 for t = 255*255. > > I made some further enquires: > - also 16bit arithmetic only. > - it doesn't gives the exact results just 4.241.987 out of 16.777.216 > possible cases, i.e., is exact 75% of the times. > - very easy to code, in fact already done for MMX code (see initial > patch attached) > - it also gives a 6% speedup, in my benchmark from the previous 3.637088 > sec to 3.429032 sec. Plus a little more when I optimize the assembly code > a little further since it the abcense of rounding frees some registers. > - and glean likes it, since it just give an error of 0.522796 !! > > I guess we've got ourselves a new method: Fonseca's method!! He!He! > > Now for real. I would appreciate comments on this as I don't believe much > in wonderful discoveries.. As long as the code passes the glean and conform blend tests and the 255*255=255 identity is satisfied then I'm happy with it. I'll apply your new MMX patch. BTW, are you interested in writing MMX functions for the blend_add and blend_modulate functions? Those would be useful, and would probably be trivial for you after doing blend_transparency. -Brian _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
