Keith Whitwell wrote: > Brian Paul wrote: >> Kristian Høgsberg wrote: >>> Hi, >>> >>> I have this branch with DRI interface changes that I've been >>> threatening to merge on several occasions: >>> >>> http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2 >>> >>> I've just rebased to todays mesa and it's ready to merge. Ian >>> reviewed the changes a while back gave his ok, and from what we >>> discussed at XDS2007, I believe the changes there are compatible with >>> the Gallium plans. >>> >>> What's been keeping me from merging this is that it breaks the DRI >>> interface. I wanted to make sure that the new interface will work for >>> redirected direct rendering and GLXPixmaps and GLXPbuffers, which I >>> now know that it does. The branch above doesn't included these >>> changes yet, it still uses the sarea and the old shared, static back >>> buffer setup. This is all isolated to the createNewScreen entry >>> point, though, and my plan is to introduce a new createNewScreen entry >>> point that enables all the TTM features. This new entry point can >>> co-exist with the old entry point, and a driver should be able to >>> support one or the other and probably also both at the same time. >>> >>> The AIGLX and libGL loaders will look for the new entry point when >>> initializing the driver, if they have a new enough DRI/DRM available. >>> If the loader has an old style DRI/DRM available, it will look for the >>> old entry point. >>> >>> I'll wait a day or so to let people chime in, but if I don't hear any >>> "stop the press" type of comments, I'll merge it tomorrow. >> >> This is basically what's decsribed in the DRI2 wiki at >> http://wiki.x.org/wiki/DRI2, right? >> >> The first thing that grabs my attention is the fact that front color >> buffers are allocated by the X server but back/depth/stencil/etc >> buffers are allocated by the app/DRI client. >> >> 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. > > So I would say that at least between a fullscreen clear and either > swap-buffers or some appropriate flush (glXWaitGL ??), we can treat the > rendering operations as atomic and have a lot of flexibility in terms of > how we schedule actual rendering and whether we actually share a buffer > or not. Note that swapbuffers is as good as a clear from this > perspective as it can leave the backbuffer in an undefined state.
On the other hand, a pair of purposely-written programs could clear-a, draw-a, draw-b, swap-b and the results should be coherent. That's how I read the spec. > I'm not just splitting hairs for no good reason - the ability for the 3d > driver to know the size of the window it is rendering to while it is > emitting commands, and to know that it won't change size until it is > ready for it to is really crucial to building a solid driver. Agreed. > The trouble with sharing a backbuffer is what to do about the situation > where two clients end up with different ideas about what size the buffer > should be. > > 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. > > 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. I don't know the answers to this either. There's probably very few, if any, GLX programs in existance that rely on the behaviour of this. Chromium is one program that renders into other app's windows (Render SPU's render_to_app_window option). But in that case, the owner of the window no longer renders into the window once Chromium takes over. I think the "VirualGL" utility might rely on reading other client's GLX buffers, but I'd have to take a closer look. I'm just finishing up a new GLX test app that accesses another client's GLX window. It's a buffer "snooper" similar to a utility that SGI had on their IRIX systems. Basically, it lets you view another app's window's back/stencil/z buffers. I used it a lot back in the day and always missed it when I left IRIX. I'll check it in soon. I could probably quickly whip up another test that does coordinating rendering into one window from two processes. I could run it with NVIDIA's driver and see what happens there. > etc. > > All of these are superficial approaches. My belief is that if we really > make an attempt to understand the sharing semantics encoded in the GLX > spec, and interpret that in the terms of allowable ordering of rendering > operations of separate clients, a favorable implementation is possible. > > Kristian - I apologize that I only ever look at this briefly & under > duress... I'm off to read the spec properly now. Kristian, I also apologize for not tracking this stuff closer and don't mean to cause you more work. -Brian ------------------------------------------------------------------------- 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
