On Tue, 2006-03-14 at 08:40 +0000, Keith Whitwell wrote: > David Reveman wrote: > > 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. > > It's very easy just to go ahead and accelerate copypixels directly. Why > not do that instead?
We should do that too. However, CopySubBufferMESA is a good idea for a few reasons: 1. To be able to sync partial screen updates to vblank when using indirect rendering I need protocol support for something like CopySubBufferMESA anyhow. 2. When I have a separate thread that waits for vblank and updates the screen, it's a big win to be able to use CopySubBufferMESA instead of CopyPixels as I don't have to switch context every time I update the screen. 3. Really simple to implement in all existing drivers and gives optimal performance. > > There's no requirement to have a memory manager or anything else hard, > just check some state to make sure the blitter is appropriate, scan the > cliprects and emit the blits... Yes, I know. I would have tried to do this if fast CopyPixels was all I needed. > > The i915 driver on the texman_0_1_branch has this code, but it is not > tied to the memory manager work at all. > -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
