Re: Merging DRI interface changes

[Brian P. <bri...@tu...>]

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