On Mon, 8 Jul 2002, Brian Paul wrote:
> 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 mentioned in my original reply, the r128 driver has the same problem
with texenv in single-buffer mode. I think single-buffer mode is actually
a double-buffered visual drawing on the front buffer, but I'll have to
check that. At least with the card I have, the r128 uses software
fallbacks for GL_BLEND texture environments where there is an environment
color. If I turn off the background ('g'), and cycle through the
background colors with 'c', the textures in the BLEND column are all
blended against the back buffer instead of the front buffer. This problem
could be tested on the Radeon driver by forcing a software fallback for
the GL_BLEND texture environment, as an example. I don't have a Radeon,
so I can't test this.
> 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
> _______________________________________________
> Mesa3d-dev mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
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
