Graham Hay wrote: > --- Leif Delgass <[EMAIL PROTECTED]> wrote: > >>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.
The driver should assume the second case. swrast->Driver.SetReadBuffer() will get called for the first case, as needed. >>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. That could be. I'm sure these kinds of rendering paths were tested when I ran the conformance tests on all the drivers last year. But every driver is a bit different. > Heres a random thought. Assuming that > > 1. Mesa indirect, pure software is all fine which it seems to be, > it can still present double-buffering, and presumably gets the correct read > buffer. > > 2. The problem then lies in the less tested path of hooking into the hw > driver specific part (esp with a card with heavy software fallback?). In which > case its more in the Mesa part. Or theres an assumption which doesn't hold > true on the mach64 requiring some workaround. Which is what I think Leif > is saying. > > Then wouldn't trying the same thing on a different DRI driver show > a) the same problem - indicating the Mesa part or > b) work fine - indicating something wrong in mach64? Right. If you find that the problem really is in Mesa I'll happily apply a patch or fix whatever's broken. As I said, I plan to simplify this stuff in Mesa 4.1. I think a single swrast->Driver.SetBuffer() function to specify both the draw destination and the read source would be sufficient. This would be relevant to software rendering, but not hardware rendering. There would also be ctx->Driver.SetReadBuffer() and ctx->Driver.SetDrawBuffer() which are simply called from glReadBuffer() and glDrawBuffer(). These would be used for setting hardware state, but ignored by software rendering. -Brian ------------------------------------------------------- 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
