-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEFex2X1gOwKyEAw8RAkGYAJ9gd2sGJ+SxmrqGeuCWqytPEHAd5wCaAgPF 4VsVK+Soh90EBpCCs66uOik= =wNTG -----END PGP SIGNATURE----- ------------------------------------------------------- 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
