On 10/11/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: > Brian Paul wrote: ... > > If two GLX clients render to the same double-buffered GLX window, each > > is going to have a different/private back color buffer, right? That > > doesn't really obey the GLX spec. The renderbuffers which compose a GLX > > drawable should be accessible/shared by any number of separate GLX > > clients (like an X window is shared by multiple X clients). > > I guess I want to know what this really means in practice. > > Suppose 2 clients render to the same backbuffer in a race starting at > time=0, doing something straightforward like (clear, draw, swapbuffers) > there's nothing in the spec that says to me that they actually have to > have been rendering to the same surface in memory, because the > serialization could just be (clear-a, draw-a, swap-a, clear-b, draw-b, > swap-b) so that potentially only one client's rendering ends up visible.
I've read the GLX specification a number of times to try to figure this out. It is very vague, but the only way I can make sense of multiple clients rendering to the same drawable is if they coordinate between them somehow. Maybe the scenegraph is split between several processes: one client draws the backdrop, then passes a token to another process which then draws the player characters, and then a third draws a head up display, calls glXSwapBuffers() and passes the token back to the first process. Or maybe they render in parallel, but to different areas of the drawable, synchronize when they're all done and then one does glXSwapBuffers() and they start over on the next frame. ... > So, if it is necessary to share backbuffers, then what I'm saying is > that it's also necessary to dig into the real details of the spec and > figure out how to avoid having the drivers being forced to change the > size of their backbuffer halfway through rendering a frame. This is a bigger issue to figure out than the shared buffer one. I know you're looking to reduce the number of changing factors during rendering (clip rects, buffer sizes and locations), but the driver needs to be able to pick up new buffers in a few more places than just swap buffers. But I think we agree that we can add that polling in a couple of places in the driver (before starting a new batch buffer, on flush, and maybe other places) and it should work. > I see a few options: > 0) The old DRI semantics - buffers change shape whenever they feel > like > it, drivers are buggy, window resizes cause mis-rendered frames. > > 1) The current truly private backbuffer semantics - clean drivers but > some deviation from GLX specs - maybe less deviation than we actually think. > > 2) Alternate semantics where the X server allocates the buffers but > drivers just throw away frames when they find the buffer has changed > shape at the end of rendering. I'm sure this would be nonconformant, at > any rate it seems nasty. (i915 swz driver is forced to do this). > > 3) Share buffers with a reference counting scheme. When a client > notices the buffer needs a resize, do the resize and adjust refcounts - > other clients continue with the older buffer. What happens when a > client on the older buffer calls swapbuffers -- I'm sure we can figure > out what the correct behaviour should be. 3) Sounds like the best solution and it's basically what I'm proposing. For the first implementation (pre-gallium), I'm looking to just reuse the existing getDrawableInfo polling for detecting whether new buffers are available. It won't be more or less broken than the current SAREA scheme. When gallium starts to land, we can fine-tune the polling to a few select points in the driver. The DRI driver interface changes I'm proposing here should not be affected by these issues though. Detecting that the buffers changed and allocating and attaching new ones is entirely between the DRI driver and the DRM. When we're ready to add the TTM functionality to a driver we add the new createNewScreen entry point I mentioned and that's all we need to change. So, in other words, I believe we can move forward with this merge while we figure out the semantics of the resizing-while-rendering case. Kristian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
