On Mon, 2006-03-13 at 14:04 -0800, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Reveman wrote: > > On Mon, 2006-03-13 at 10:45 -0800, Ian Romanick wrote: > >>David Reveman wrote: > >> > >>>This patch adds direct and indirect rendering support for > >>>GLX_MESA_copy_sub_buffer. Intel, r200 and r300 drivers are the only > >>>drivers I've implemented support for so far. I've only tried the intel > >>>implementation and that seems to be working OK. I've attached a patch > >>>for CVS head and one for 6.4.2. > >> > >>I think the spec for this extension and the code implementing it needs a > >>slight update. The problem is that the extension assumes that > >>SwapBuffers is implemented by copying the back buffer to the front. > >>However, this is *not* always the case. The result is that this > >>extension does not produce the desired results with page flipping. > >> > >>However, it is possible for an application to detect / request the copy > >>behavior by using GLX_OML_swap_method. An fbconfig with copy semantics > >>can be requested by using "GLX_SWAP_METHOD_OML, GLX_SWAP_COPY_OML" in > >>the attribs list. If not particular method is requested, the current > >>method can be queried via glXGetFBConfigAttrib. > >> > >>The only rub is that most of our drivers only advertise a > >>GLX_SWAP_METHOD_OML of GLX_SWAP_UNDEFINED_OML. This is because, in the > >>drivers that support page-flipping, we switch between GLX_SWAP_COPY_OML > >>and GLX_SWAP_EXCHANGE_OML on the fly. We can easilly modify the drivers > >>to adverteise GLX_SWAP_COPY_OML fbconfigs and enforce that behavior. > >> > >>Currently none of the drivers actually advertise GLX_SWAP_EXCHANGE_OML > >>fbconfigs. > >> > >>http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_swap_method.txt > >> > >>My opinion is that we should modify GLX_MESA_copy_sub_buffer to, at the > >>very least, note that the desired behavior is only guaranteed for the > >>GLX_SWAP_COPY_OML case. We may even want to say that, if > >>GLX_OML_swap_method is supported, it is an error to call > >>glXCopySubBufferMESA when GLX_SWAP_METHOD_OML is not GLX_SWAP_COPY_OML. > > > > Yes, I though about this and I think the best is that CopySubBuffer is > > separated from buffer swapping so that no extensions that control buffer > > swapping are affected by this extension. This is how the current > > implementation should behave. E.g. it's not waiting for vblank or > > incrementing swap counters. > > > > Yes, the spec needs to be updated (at least with some protocol). > > This doesn't have *anything* to do with swap counters for waiting for > the vblank. If the SwapBuffers uses page flipping, copying the back > buffer to the front buffer will give different results than if > SwapBuffers uses copying. > > Consider the following sequence: > > - - clear backbuffer > - - draw square to backbuffer > - - call glXSwapBuffers > - - clear backbuffer > - - draw circle to backbuffer > - - call glXSwapBuffers > > If SwapBuffers uses page flipping, a call to CopySubBufferMESA(0,0, > width, height) would restore the square, *not* the circle. I'd guess > that in most (all?) cases this is not what the user wants. > > My opinion is that we should modify GLX_MESA_copy_sub_buffer to, at the > very least, note that the desired behavior is only guaranteed for the > case where SwapBuffers uses a copy (i.e., GLX_SWAP_COPY_OML). We may > even want to say that, if it is possible to determine how SwapBuffers is > implemented (e.g., GLX_OML_swap_method is supported), it is an error to > call glXCopySubBufferMESA when page flipping may be used (i.e., > GLX_SWAP_METHOD_OML is not GLX_SWAP_COPY_OML). > > No matter what we put in the spec, there *is* a relationship between > CopySubBufferMESA and the implementation of SwapBuffers.
I thought that a call to SwapBuffers would always make the content of the back buffer undefined. So if you want to use CopySubBufferMESA for quickly repainting part of the buffer as the in the spec, you would never use SwapBuffers. By saying that I want CopySubBufferMESA separated from buffer swapping, I ment that I want the relationship between CopySubBufferMESA and the implementation of SwapBuffers to be the same as the relationship between CopyPixels and SwapBuffers. We don't really need this for "quickly repainting 3D windows on expose events" as the spec says. We only need it for efficiently copying part of the back buffer to the front buffer. However, I agree, the spec needs to be updated to make all this more clear. -David ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
