Initial DRI3000 protocol specs available

[Keith Packard]

James Jones <jajones at nvidia.com> writes:

> 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.

I don't know of anyone else doing user-mode ring submission, and that's
the key here -- if you're diving into the kernel to submit commands to
the HW, you can make it work pretty easily, even if your hardware is all
multi-dispatch.

> 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:

Thanks for joining in when you saw something relevant.

Of course we're trying to drain the ocean. Mostly, I want to make sure
that fixing the DRI2 problems isn't going to lead us to a dead-end where

> 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.

That was Owen's idea, and I think it's a pretty good one -- just hand
the application buffer to the compositor and let it deal with things
From there. One obvious trivial improvement will be for full-screen
applications where the pixmap handed to the compositor will just get
handed to the video hardware for scanout; no horror-show 'unredirect
full-screen' stuff.

> -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.

I think doing this lazily has a lot of merit, it makes the APIs cleaner
as you're passing real XIDs around all the time. And, it obviates any
special cases for 'omg, I want to change sizes or other parameters'.

> -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.

Yeah, we're stuck with OpenGL swap semantics, so we have to make sure
whatever we implement can do that exactly. Suggestions on how to make
that work without passing essentially the OpenGL data all the way
through the chain are welcome; it's certainly ugly this way.

> http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization.pdf

I've got meetings all week, but I'll try to get this reviewed and see if
I can't make sense of what you're proposing and what I need.

> Thanks,

I'm really glad you've already thought through many of these issues;
would be great to provide a single unified set of semantics for
applications that work across all of the drivers.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130309/0089f761/attachment-0001.pgp>