On Tue, 2009-07-14 at 15:29 -0700, Nicolai Hähnle wrote: > Am Tuesday 14 July 2009 23:37:17 schrieb Brian Paul: > > The glean exactRGBA test has always failed with Mesa (with sw > > rendering at least). The failures come from a sequence of > > int->float->int conversions which don't meet the GL spec. > > > > In particular, when glColor4us() or glColor4ui() are used to set the > > drawing color, the N-bit integer frame buffer values should match the > > upper N bits of the GLushort or GLuint value originally passed in. > > > > Because of int->float->int conversions it's a little tricky to > > maintain the N-bit identity requirement. > > > > The attached patch fixes the exactRGBA failures. I haven't seen any > > regressions but some additional eyes should take a look. > > > > There are two parts: > > > > 1. Convert float->ubyte with floor(x*255.999) instead of iround(x*255.0) > > > > 2. Convert uint->float with floor((u >> 16) / 65535.0) instead of > > floor(u / 4294967295.0) This effectively converts the GLuint to a > > GLushort. This isn't ideal but I think it's "good enough" until we > > find otherwise. > > Actually, this patch is incorrect, and as far as I can tell, the OpenGL > specification is unfortunately self-contradictory. My personal opinion is > that > the current behaviour of Mesa is the sane thing to do, and the behaviour that > exactRGBA tests for is crazy and unexpected. > > It is, however, possible that I'm wrong, so let me just explain how I came to > this opinion long ago, and perhaps you can explain a mistake I made. In any > case, let the specification lawyering begin. > > The test exactRGBA is motivated by a paragraph in the section "Final Color > Processing" (2.19.9 in glspec3.0). This is, as far as I know, the only > support > for this test in the entire spec. > > And here's evidence supporting the current Mesa behaviour: > > 1. The state tables clearly state that the current color is a vector of > floating point values. All places where converting between fixed point and > floating point are mentioned require what Mesa currently does. > > 2. Consider the paragraph following the description of the Color and > SecondaryColor functions in section "Vertex Specification" (section 2.7). It > explicitly says that integer values are to be converted to floating point as > discussed in a different part of the spec (section 2.19). This section > contains a table (table 2.10) is *very* explicit about how conversions are to > be done: In the same way that Mesa currently does it. > > So the OpenGL specification contradicts itself: Either you convert in the way > mandated by table 2.10, or you support the language of section 2.19.9. Doing > both is essentially impossible. > > With that, one thing to keep in mind is that probably this should be brought > to the ARB's attention. The other thing is to choose how Mesa should behave, > and here I vote for going with what's sane. > > And in my opinion, Mesa current behaviour is clearly the sane choice. Why? > Because that's really what you expect from fixed point <-> floating point > conversion (principle of least surprise and so on). > > As a consequence, and perhaps after checking in with the ARB, it seems wise > to > remove or appropriately modify that exactRGBA test). > > cu, > Nicolai
Fantastic -- I couldn't agree more. I'm glad I'm not the only exatRGBA hater here... Keith ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
