mesa3d-dev

[Mesa3d-dev] Framebuffers in mesa

[Maciej C. <m.c...@gm...>]

Hi all,

I've got some questions regarding FBOs in mesa. I hope you'll be able to 
answer at least some of them.

GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer, ReadBuffer, 
WinSysDrawBuffer, WinSysReadBuffer) and one to gl_renderbuffer 
(CurrentRenderbuffer). gl_framebuffer struct contains amongs other fields:
_ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer, _StencilBuffer.
Now having in mind that r300 wraps all gl_renderbuffers and gl_texture_object 
(they contain HW buffer objects that I'm interested in), what is the proper way 
to get to read and draw buffers?

What operations use ctx->_ReadBuffer besides glReadPixels,glCopyPixels and 
glCopyTex(Sub)Image?

What operations use ctx->_DrawBuffer besides rendering operations? 
(glBegin/glEnd, glDrawElements, glDrawArrays, ...)

Am I correct that for ctx->_DrawBuffer field _ColorReadBuffer is unused, and for 
ctx->_ReadBuffer _ColorDrawBuffers is unused?

Regards,
Maciej

Re: [Mesa3d-dev] Framebuffers in mesa

[Brian P. <bri...@gm...>]

On Fri, Mar 12, 2010 at 12:19 PM, Maciej Cencora <m.c...@gm...> wrote:
> Hi all,
>
> I've got some questions regarding FBOs in mesa. I hope you'll be able to
> answer at least some of them.
>
> GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer, ReadBuffer,
> WinSysDrawBuffer, WinSysReadBuffer) and one to gl_renderbuffer
> (CurrentRenderbuffer). gl_framebuffer struct contains amongs other fields:
> _ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer, _StencilBuffer.
> Now having in mind that r300 wraps all gl_renderbuffers and gl_texture_object


Do you mean that r300 subclasses gl_renderbuffer and
gl_texture_object?  That's what I think you mean.  The term "wrapping"
has a special meaning for renderbuffers (see below).


> (they contain HW buffer objects that I'm interested in), what is the proper way
> to get to read and draw buffers?

The current "read" framebuffer is at ctx->ReadBuffer.  The current
drawing framebuffer is ctx->DrawBuffer.

Then, if you're reading _colors_ the renderbuffer to use is
ctx->ReadBuffer->_ColorReadBuffer.  If you want to read _stencil_
values, it would be ctx->ReadBuffer->_StencilBuffer.  Similarly for
Z/depth, etc.

To draw to color buffers (there may be more than one) you'll want
ctx->DrawBuffer->_ColorDrawBuffers[].  For stencil it's
ctx->DrawBuffer->_Stencil, etc.

Renderbuffers typically correspond to a region of video memory.  How
that works is driver-dependent.


> What operations use ctx->_ReadBuffer besides glReadPixels,glCopyPixels and
> glCopyTex(Sub)Image?

glCopyColorTable and maybe some other obscure functions.  You got the main ones.


> What operations use ctx->_DrawBuffer besides rendering operations?
> (glBegin/glEnd, glDrawElements, glDrawArrays, ...)

That's basically it, plus glClear.


> Am I correct that for ctx->_DrawBuffer field _ColorReadBuffer is unused, and for
> ctx->_ReadBuffer _ColorDrawBuffers is unused?

No, they're used - see above.  The _ColorReadBuffer field depends on
the glReadBuffer() call.  The _ColorDrawBuffers[] pointers depend on
the glDrawBuffer() and glDrawBuffersARB() functions.


It's important to understand the heirarchy of gl_framebuffers and
gl_renderbuffers.

Each framebuffer object has a collection of renderbuffers.

Renderbuffers may also act as wrappers for gl_texture_object when
doing render to texture.  In this case, the renderbuffer acts as a 2D
view into a level/slice/face of a texture object.

Also, we have special depth/stencil renderbuffers which wrap combined
depth/stencil buffers.  See main/depthstencil.c  That's mainly for
software rendering, though.

-Brian

Re: [Mesa3d-dev] Framebuffers in mesa

[Maciej C. <m.c...@gm...>]

Dnia sobota, 13 marca 2010 o 01:10:01 Brian Paul napisał(a):
> On Fri, Mar 12, 2010 at 12:19 PM, Maciej Cencora <m.c...@gm...> 
wrote:
> > Hi all,
> >
> > I've got some questions regarding FBOs in mesa. I hope you'll be able to
> > answer at least some of them.
> >
> > GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer,
> > ReadBuffer, WinSysDrawBuffer, WinSysReadBuffer) and one to
> > gl_renderbuffer
> > (CurrentRenderbuffer). gl_framebuffer struct contains amongs other
> > fields: _ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer,
> > _StencilBuffer. Now having in mind that r300 wraps all gl_renderbuffers
> > and gl_texture_object
> 
> Do you mean that r300 subclasses gl_renderbuffer and
> gl_texture_object?  That's what I think you mean.  The term "wrapping"
> has a special meaning for renderbuffers (see below).

Yes, r300 subclasses these structs (and additionally wraps texture objects 
with renderbuffers).

> 
> > (they contain HW buffer objects that I'm interested in), what is the
> > proper way to get to read and draw buffers?
> 
> The current "read" framebuffer is at ctx->ReadBuffer.  The current
> drawing framebuffer is ctx->DrawBuffer.
> 
> Then, if you're reading _colors_ the renderbuffer to use is
> ctx->ReadBuffer->_ColorReadBuffer.  If you want to read _stencil_
> values, it would be ctx->ReadBuffer->_StencilBuffer.  Similarly for
> Z/depth, etc.

That's what I'm doing, but sometimes it happens that ctx->ReadBuffer-
>_ColorReadBuffer is NULL (see drivers/dri/radeon/radeon_tex_copy.c). Is this a 
legal situation? What should I do then if user requested glCopyTexImage or 
glCopyPixels?

> 
> To draw to color buffers (there may be more than one) you'll want
> ctx->DrawBuffer->_ColorDrawBuffers[].  For stencil it's
> ctx->DrawBuffer->_Stencil, etc.
> 
> Renderbuffers typically correspond to a region of video memory.  How
> that works is driver-dependent.
> 
> > What operations use ctx->_ReadBuffer besides glReadPixels,glCopyPixels
> > and glCopyTex(Sub)Image?
> 
> glCopyColorTable and maybe some other obscure functions.  You got the main
>  ones.
> 
> > What operations use ctx->_DrawBuffer besides rendering operations?
> > (glBegin/glEnd, glDrawElements, glDrawArrays, ...)
> 
> That's basically it, plus glClear.
> 
> > Am I correct that for ctx->_DrawBuffer field _ColorReadBuffer is unused,
> > and for ctx->_ReadBuffer _ColorDrawBuffers is unused?
> 
> No, they're used - see above.  The _ColorReadBuffer field depends on
> the glReadBuffer() call.  The _ColorDrawBuffers[] pointers depend on
> the glDrawBuffer() and glDrawBuffersARB() functions.
> 

I still don't get it. I see a reason in using _ColorReadBuffer in context of 
ctx->_ReadBuffer but not in context of ctx->_DrawBuffer (and similarly for 
_ColorDrawBuffers).

Thanks for explanation,
Maciej

> 
> It's important to understand the heirarchy of gl_framebuffers and
> gl_renderbuffers.
> 
> Each framebuffer object has a collection of renderbuffers.
> 
> Renderbuffers may also act as wrappers for gl_texture_object when
> doing render to texture.  In this case, the renderbuffer acts as a 2D
> view into a level/slice/face of a texture object.
> 
> Also, we have special depth/stencil renderbuffers which wrap combined
> depth/stencil buffers.  See main/depthstencil.c  That's mainly for
> software rendering, though.
> 
> -Brian
> 

Re: [Mesa3d-dev] Framebuffers in mesa

[Brian P. <bri...@gm...>]

On Sat, Mar 13, 2010 at 3:20 AM, Maciej Cencora <m.c...@gm...> wrote:
> Dnia sobota, 13 marca 2010 o 01:10:01 Brian Paul napisał(a):
>> On Fri, Mar 12, 2010 at 12:19 PM, Maciej Cencora <m.c...@gm...>
> wrote:
>> > Hi all,
>> >
>> > I've got some questions regarding FBOs in mesa. I hope you'll be able to
>> > answer at least some of them.
>> >
>> > GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer,
>> > ReadBuffer, WinSysDrawBuffer, WinSysReadBuffer) and one to
>> > gl_renderbuffer
>> > (CurrentRenderbuffer). gl_framebuffer struct contains amongs other
>> > fields: _ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer,
>> > _StencilBuffer. Now having in mind that r300 wraps all gl_renderbuffers
>> > and gl_texture_object
>>
>> Do you mean that r300 subclasses gl_renderbuffer and
>> gl_texture_object?  That's what I think you mean.  The term "wrapping"
>> has a special meaning for renderbuffers (see below).
>
> Yes, r300 subclasses these structs (and additionally wraps texture objects
> with renderbuffers).
>
>>
>> > (they contain HW buffer objects that I'm interested in), what is the
>> > proper way to get to read and draw buffers?
>>
>> The current "read" framebuffer is at ctx->ReadBuffer.  The current
>> drawing framebuffer is ctx->DrawBuffer.
>>
>> Then, if you're reading _colors_ the renderbuffer to use is
>> ctx->ReadBuffer->_ColorReadBuffer.  If you want to read _stencil_
>> values, it would be ctx->ReadBuffer->_StencilBuffer.  Similarly for
>> Z/depth, etc.
>
> That's what I'm doing, but sometimes it happens that ctx->ReadBuffer-
>>_ColorReadBuffer is NULL (see drivers/dri/radeon/radeon_tex_copy.c). Is this a
> legal situation? What should I do then if user requested glCopyTexImage or
> glCopyPixels?

That shouldn't normally happen.  Do you have a test program that exhibits that?

If a user specifies a read buffer (like GL_COLOR_ATTACHMENT0) that's
missing in the current FBO, the error
GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT should be generated during
FBO validation.  In that case _ColorReadBuffer would be NULL.



>> To draw to color buffers (there may be more than one) you'll want
>> ctx->DrawBuffer->_ColorDrawBuffers[].  For stencil it's
>> ctx->DrawBuffer->_Stencil, etc.
>>
>> Renderbuffers typically correspond to a region of video memory.  How
>> that works is driver-dependent.
>>
>> > What operations use ctx->_ReadBuffer besides glReadPixels,glCopyPixels
>> > and glCopyTex(Sub)Image?
>>
>> glCopyColorTable and maybe some other obscure functions.  You got the main
>>  ones.
>>
>> > What operations use ctx->_DrawBuffer besides rendering operations?
>> > (glBegin/glEnd, glDrawElements, glDrawArrays, ...)
>>
>> That's basically it, plus glClear.
>>
>> > Am I correct that for ctx->_DrawBuffer field _ColorReadBuffer is unused,
>> > and for ctx->_ReadBuffer _ColorDrawBuffers is unused?
>>
>> No, they're used - see above.  The _ColorReadBuffer field depends on
>> the glReadBuffer() call.  The _ColorDrawBuffers[] pointers depend on
>> the glDrawBuffer() and glDrawBuffersARB() functions.
>>
>
> I still don't get it. I see a reason in using _ColorReadBuffer in context of
> ctx->_ReadBuffer but not in context of ctx->_DrawBuffer (and similarly for
> _ColorDrawBuffers).

Suppose I call glDrawBuffers(GL_FRONT_AND_BACK).  That means we need
to render into two colorbuffers simultaneously (or four if stereo
mode).  The render buffers in question will be found in
ctx->DrawBuffer->ColorDrawBuffers[] and
ctx->DrawBuffer->_NumColorDrawBuffers = 2.

If we didn't have those derived fields/pointers we'd have to dig
around through other FBO state to find where we're supposed to draw
to.

-Brian