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 ------------------------------------------------------------------------------ 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
