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?
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...
The i915 driver on the texman_0_1_branch has this code, but it is not
tied to the memory manager work at all.
Keith
-------------------------------------------------------
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
