On Sun, 7 Jul 2002, Brian Paul wrote: > The notion of 'current read buffer' is more complicated than one would > first expect. There are basically two situations in which you need to > read from a color buffer: > > 1. glRead/CopyPixels() and glAccum() > 2. blending/logicops/masking > > In the first case, the source buffer is whatever glReadBuffer() indicates. > Furthermore, the source for the pixels may be a completely different window. > The glXMakeContextCurrent() and glXMakeCurrentRead() functions let you > specify different drawables (windows) for reading and writing pixels. That's > why Mesa's swrast->Driver.SetReadBuffer() takes a GLframebuffer argument. > > In the second case, the source buffer is what glDrawBuffer() indicates. > Mesa considers the second case to be the more common and usually keeps > the "default read buffer" = "default draw buffer". > > So the basic idea is to read spans from whatever the ctx->Driver.SetDrawBuffer() > call indicates, until overridden by swrast->Driver.SetReadBuffer().
The problem is that the read buffer for these two cases can be different at a given state, but swrast->Driver.ReadRGBASpan() and friends always read from the buffer set by swrast->Driver.SetReadBuffer() (unless SetReadBuffer hasn't been called, in which case the default read buffer is GL_BACK_LEFT for a double-buffered visual and GL_FRONT_LEFT for a single buffer visual). This is because the hardware driver doesn't know if these functions are called by Mesa for the first or second case you mention. In Graham's test progam, the visual is double-buffered, so the read buffer is set by the driver to the back buffer initially. Then glDrawBuffer(GL_FRONT) is called before the logic ops, but the read buffer remains GL_BACK. With this state, glReadPixels should read from GL_BACK, but Mesa software blending/logicops should read from GL_FRONT (the DrawBuffer). However, looking at s_logic.c, Mesa uses the driver's ReadRGBASpan/Pixels functions, which can't handle this discrepency. What I'm saying is that Mesa would have to explicitly call swrast->Driver.SetReadBuffer() to "fool" the driver to read from the draw buffer (the "default read buffer" = "default draw buffer" state you mentioned for the Mesa swrast functions). This problem probably hasn't been noticed in other drivers because they use fewer software fallbacks than mach64, and drawing on the back buffer is the common case. So it looks to me like there isn't anything I can do to fix this problem from the hardware driver end. Am I missing something or is this really a Mesa bug? -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
