On Sat, Mar 13, 2010 at 3:20 AM, Maciej Cencora <m.cenc...@gmail.com> 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.cenc...@gmail.com> > 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
