Keith Whitwell wrote: > Brian Paul wrote: >> 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. > > Yes, but only if there was a flush-a in there somewhere, and even then > you'd need something to ensure that it didn't come out like: > > draw-b, swap-b, clear-a, draw-a > > I think you'd have to do > > A: clear, draw, glflush, send a signal to B > B: wait for A's signal, draw, swapbuffers > > Even without me trying to play with the GLX semantics, it's pretty > normal for A and B to buffer up whole frame-worths of rendering in a > single DMA buffer, and not to fire that buffer until you get a flush. > Without the flushes and explicit signals, any ordering is possible as > long as it respects the local orderings inside A and B.
Yes, I intended that flushes and synchronization signals would be used. >>> 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. > > Agreed, but also nv behaviour (whatever it may be) is not the only > option under the spec -- though if they break the spec that would be > interesting to know. I suspect they respect it when the window size > doesn't change, but I wonder what happens when two processes are > accessing a window which is subject to resize. I guess I'll write another test app and see what happens. > Maybe we're examining the wrong spec here. My concerns are all about > what happens when the window changes size -- what does X tell us about > the contents of a window under those circumstances? I believe it depends on backing store and bit gravity, etc. The difference with X drawing is there's really only one renderer and it knows about window size changes right when they happen. > Does the GLX spec > actually specify *anything* about this situation??? I don't think so. -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
