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.
>
>> 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.
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? Does the GLX spec
actually specify *anything* about this situation???
Keith
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
