On 03/07/2013 05:17 PM, Keith Packard wrote:
* PGP Signed by an unknown key
James Jones <[email protected]> writes:
There didn't seem to be much interest outside of NVIDIA, so
besides fence sync, the ideas are tabled internally ATM.
This shouldn't surprise you though -- no-one else needs this kind of
synchronization, so it's really hard for anyone to evaluate it. And,
DRI2 offers 'sufficient' support for the various GL sync extensions.
I was referring to the multi-buffer/tear-free presentation part, not the
synchronization parts. I still rather surprised everyone thinks
implicit synchronization is a good idea though. I don't think we're the
only ones that have loosely defined command buffer processing in HW
anymore. Meh.
So, what I'd like to know is if you think nVidia could take advantage of
the Swap extension so that nVidia 3D applications could do the whole
Swap redirect plan? If so, then I'm a lot more interested in figuring
out how we can get apps using the necessary fencing to actually make it
work right.
Sorry, I've been ignoring this thread because of the DRI3000 title, so I
missed the point where it defined a generic swap mechanism in X
protocol. From my reading, applications do roughly this in the spec:
Pixmap pix[N] = MakeListOfPixmaps(N)
Window win = MakeWindow();
int n = 0;
while (1) {
// Stuff here to ensure pix[n] is idle.
Render(pix[n]);
SwapRegion(win, pix[n]);
}
I think I saw in one branch of the thread that you might allow
redirecting the swap request out to a composite manager rather than
processing in X.
Basically that's what I proposed (and Aaron presented some of at XDC) a
few years ago and got no feedback. However, my full proposal included:
-setting the list of pixmaps associated with a window up front, so that
the composite manager or GL applications could query them and do work
once to bind them in to GL. This is pretty expensive. With your
proposal, this could probably be done lazily and tracked in a cache-type
thing, but if applications wanted to be dumb and generate a new pixmap
for every frame, nothing is stopping them. Applications would do
something like:
Pixmap pix[N]
XCreateWindowPixmaps(win, N, pix /* out */);
up front, and composite managers would get an event notifying them that
<win> now has those N pixmaps associated with it. Swaps would be done
by indexing into that array rather than sending the actual pixmap ID.
-Using sync object lists in place of all the hard-coded timing
information. We've never been a fan of the OML style swap timing
semantics. It doesn't line up well with our HW. Why not allow
arbitrary fence objects to dictate when the swapping occurs? Then apps
that just want a simple vsync can just send a vsync fence. Apps that
want exact timing can query what types of counters are available and get
exact timing on different HW that supports different timers.
-I had a bunch of GLX proposals to solve that mess.
-Redirecting "present" operations (or swaps) to the composite manager
was central to the proposal.
It looks like a lot of the details and psuedo-code didn't make it in the
final public presentation, just a high-level overview. I'll see if I
can dig up more of that. Here's the URL to the presentation. Just skip
all the fence sync parts.
http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization.pdf
Thanks,
-James
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
