Initial DRI3000 protocol specs available

[James Jones]

On 03/07/2013 05:17 PM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> James Jones <jajones at nvidia.com> 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