On 2002.04.12 19:20 Allen Akin wrote: > ... It might be related to deep color channels, or possibly > to glean tests other than the basic blending tests. ...
That was it. I'm really sorry for all the fuzz, I just remembered I'm probably the last one on earth using 16bit depth! Of course the errors would never reach 3-4 LSB to be noticed... > > Thanks for all your good work, by the way! You're welcome! > > Allen > I've made the tests again and here are the differences with and without rounding: 32c32 < GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA 0 0 --- > GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA 0 0.917705 Both pass of course! This means that we don't need that extra precision from rounding. But there is still one caveat, the results obtained wihout rounding also don't obey the 255x255 = 255 rule as t = 255*255, (t + (t >> 8)) >> 8 is 254... Making a check for a=255 in the MMX code will have its negative impact (especially because the MMX instruction set lack of opcodes for doing that). Brian, what do you think is best? a) Leave everything as it is with exact results from blending (note that, e.g., this is a waste of time when blending to a 16bit framebuffer) b) Remove the rounding, and make no check for a=255 (don't know if OpenGL spec allows for that) c) I try a little harder(*) and implement a check for a=255 (note that this could also be beneficial if this happens frequently) (*) harder means that due to the fact that two pixels are being blended at the same time I probably would have to make 4 versions of the inner loop, plus the duplication before&after do to the alignenment... thinking again I think that option c) would be very hard to be viable as the processor cycles taken to make these decisions would be enough to make the multiplication anyway, specially with the recent CPUs that have several pipelines... Jos� Fosneca _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
