Re: [Dri-devel] Software rendering and ReadBuffer (was: mach64 testing - xor logic op)

[Leif D. <lde...@re...>]

On Mon, 8 Jul 2002, Brian Paul wrote:

> Graham Hay wrote:
> > --- Leif Delgass <lde...@re...> 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.

I missed this comment before.  If we assume the second case, we'd change
the ReadBuffer (mmesa->readOffset in the driver) whenever
ctx->Driver.SetDrawBuffer() is called, right?  And you're saying that
swrast->Driver.SetReadBuffer() will be called to change to the real
ReadBuffer for glReadPixels, right?  Would Mesa then call
ctx->Driver.SetDrawBuffer() again to set the state back to ReadBuffer =
DrawBuffer for software rendering?

-- 
Leif Delgass 
http://www.retinalburn.net