James Jones <jajo...@nvidia.com> writes: > On 03/07/2013 05:17 PM, Keith Packard wrote: >> * PGP Signed by an unknown key >> >> James Jones <jajo...@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.pack...@intel.com
pgpQQIvbdeiMD.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel