From: <kr...@bi...> - 2007-10-11 16:48:15
|
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. cheers, Kristian |
From: Brian P. <bri...@tu...> - 2007-10-11 20:53:18
|
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). [Actually, re-reading the wiki part about serial numbers, it sounds like a GLX drawable's renderbuffers will be shared. Maybe that could be clarified?] Prior to DRI "private" back buffers we pretty much got this behaviour automatically (though, software-allocated accum buffers, for example, were not properly sharable). Suppose all the renderbuffers which compose a GLX drawable were allocated and resized by the X server. The DRI clients would just have poll or check the drawable size when appropriate but they wouldn't have to allocate them. I don't know if you've gone down this road at all. There's probably "interesting" issues. I'd be interested to get your thoughts on this. The second thing I'm concerned about is backward compatibility and versioning. Today the Mesa 7.1 and 7.0.1 branches depend on different DRM and DDX driver versions. It's quite a PITA to work with both branches on one system. I'm afraid DRI2 is going to be another variable to cause some headaches (not just for me but for users who don't know which versions of which pieces work or don't work together). It sounds like you've put some thought into this so maybe it won't be that bad. I guess I'd just suggest that you try to make the transition as smooth as possible and try to be forward-looking to avoid another large API change in the future. Are there other things on the horizon that'll prompt DRI3? -Brian |
From: Keith W. <ke...@tu...> - 2007-10-11 21:35:41
|
Brian Paul wrote: > Kristian H=F8gsberg 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=3Ddri2 >> >> 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. >=20 > This is basically what's decsribed in the DRI2 wiki at=20 > http://wiki.x.org/wiki/DRI2, right? >=20 > The first thing that grabs my attention is the fact that front color=20 > buffers are allocated by the X server but back/depth/stencil/etc buffer= s=20 > are allocated by the app/DRI client. >=20 > 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=20 > doesn't really obey the GLX spec. The renderbuffers which compose a GL= X=20 > drawable should be accessible/shared by any number of separate GLX=20 > 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=20 time=3D0, doing something straightforward like (clear, draw, swapbuffers)= =20 there's nothing in the spec that says to me that they actually have to=20 have been rendering to the same surface in memory, because the=20 serialization could just be (clear-a, draw-a, swap-a, clear-b, draw-b,=20 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=20 swap-buffers or some appropriate flush (glXWaitGL ??), we can treat the=20 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=20 or not. Note that swapbuffers is as good as a clear from this=20 perspective as it can leave the backbuffer in an undefined state. 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=20 emitting commands, and to know that it won't change size until it is=20 ready for it to is really crucial to building a solid driver. The trouble with sharing a backbuffer is what to do about the situation=20 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=20 that it's also necessary to dig into the real details of the spec and=20 figure out how to avoid having the drivers being forced to change the=20 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=20 some deviation from GLX specs - maybe less deviation than we actually thi= nk. 2) Alternate semantics where the X server allocates the buffers but=20 drivers just throw away frames when they find the buffer has changed=20 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=20 notices the buffer needs a resize, do the resize and adjust refcounts -=20 other clients continue with the older buffer. What happens when a=20 client on the older buffer calls swapbuffers -- I'm sure we can figure=20 out what the correct behaviour should be. 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=20 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=20 duress... I'm off to read the spec properly now. Keith |
From: <kr...@bi...> - 2007-10-11 22:44:57
|
On 10/11/07, Keith Whitwell <ke...@tu...> 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 |
From: <kr...@bi...> - 2007-10-11 22:03:02
|
T24gMTAvMTEvMDcsIEJyaWFuIFBhdWwgPGJyaWFuLnBhdWxAdHVuZ3N0ZW5ncmFwaGljcy5jb20+ IHdyb3RlOgo+IEtyaXN0aWFuIEjDuGdzYmVyZyB3cm90ZToKPiA+IEhpLAo+ID4KPiA+IEkgaGF2 ZSB0aGlzIGJyYW5jaCB3aXRoIERSSSBpbnRlcmZhY2UgY2hhbmdlcyB0aGF0IEkndmUgYmVlbgo+ ID4gdGhyZWF0ZW5pbmcgdG8gbWVyZ2Ugb24gc2V2ZXJhbCBvY2Nhc2lvbnM6Cj4gPgo+ID4gICBo dHRwOi8vY2dpdC5mcmVlZGVza3RvcC5vcmcvfmtyaC9tZXNhL2xvZy8/aD1kcmkyCj4gPgo+ID4g SSd2ZSBqdXN0IHJlYmFzZWQgdG8gdG9kYXlzIG1lc2EgYW5kIGl0J3MgcmVhZHkgdG8gbWVyZ2Uu ICBJYW4KPiA+IHJldmlld2VkIHRoZSBjaGFuZ2VzIGEgd2hpbGUgYmFjayBnYXZlIGhpcyBvaywg YW5kIGZyb20gd2hhdCB3ZQo+ID4gZGlzY3Vzc2VkIGF0IFhEUzIwMDcsIEkgYmVsaWV2ZSB0aGUg Y2hhbmdlcyB0aGVyZSBhcmUgY29tcGF0aWJsZSB3aXRoCj4gPiB0aGUgR2FsbGl1bSBwbGFucy4K PiA+Cj4gPiBXaGF0J3MgYmVlbiBrZWVwaW5nIG1lIGZyb20gbWVyZ2luZyB0aGlzIGlzIHRoYXQg aXQgYnJlYWtzIHRoZSBEUkkKPiA+IGludGVyZmFjZS4gIEkgd2FudGVkIHRvIG1ha2Ugc3VyZSB0 aGF0IHRoZSBuZXcgaW50ZXJmYWNlIHdpbGwgd29yayBmb3IKPiA+IHJlZGlyZWN0ZWQgZGlyZWN0 IHJlbmRlcmluZyBhbmQgR0xYUGl4bWFwcyBhbmQgR0xYUGJ1ZmZlcnMsIHdoaWNoIEkKPiA+IG5v dyBrbm93IHRoYXQgaXQgZG9lcy4gIFRoZSBicmFuY2ggYWJvdmUgZG9lc24ndCBpbmNsdWRlZCB0 aGVzZQo+ID4gY2hhbmdlcyB5ZXQsIGl0IHN0aWxsIHVzZXMgdGhlIHNhcmVhIGFuZCB0aGUgb2xk IHNoYXJlZCwgc3RhdGljIGJhY2sKPiA+IGJ1ZmZlciBzZXR1cC4gIFRoaXMgaXMgYWxsIGlzb2xh dGVkIHRvIHRoZSBjcmVhdGVOZXdTY3JlZW4gZW50cnkKPiA+IHBvaW50LCB0aG91Z2gsIGFuZCBt eSBwbGFuIGlzIHRvIGludHJvZHVjZSBhIG5ldyBjcmVhdGVOZXdTY3JlZW4gZW50cnkKPiA+IHBv aW50IHRoYXQgZW5hYmxlcyBhbGwgdGhlIFRUTSBmZWF0dXJlcy4gIFRoaXMgbmV3IGVudHJ5IHBv aW50IGNhbgo+ID4gY28tZXhpc3Qgd2l0aCB0aGUgb2xkIGVudHJ5IHBvaW50LCBhbmQgYSBkcml2 ZXIgc2hvdWxkIGJlIGFibGUgdG8KPiA+IHN1cHBvcnQgb25lIG9yIHRoZSBvdGhlciBhbmQgcHJv YmFibHkgYWxzbyBib3RoIGF0IHRoZSBzYW1lIHRpbWUuCj4gPgo+ID4gVGhlIEFJR0xYIGFuZCBs aWJHTCBsb2FkZXJzIHdpbGwgbG9vayBmb3IgdGhlIG5ldyBlbnRyeSBwb2ludCB3aGVuCj4gPiBp bml0aWFsaXppbmcgdGhlIGRyaXZlciwgaWYgdGhleSBoYXZlIGEgbmV3IGVub3VnaCBEUkkvRFJN IGF2YWlsYWJsZS4KPiA+IElmIHRoZSBsb2FkZXIgaGFzIGFuIG9sZCBzdHlsZSBEUkkvRFJNIGF2 YWlsYWJsZSwgaXQgd2lsbCBsb29rIGZvciB0aGUKPiA+IG9sZCBlbnRyeSBwb2ludC4KPiA+Cj4g PiBJJ2xsIHdhaXQgYSBkYXkgb3Igc28gdG8gbGV0IHBlb3BsZSBjaGltZSBpbiwgYnV0IGlmIEkg ZG9uJ3QgaGVhciBhbnkKPiA+ICJzdG9wIHRoZSBwcmVzcyIgdHlwZSBvZiBjb21tZW50cywgSSds bCBtZXJnZSBpdCB0b21vcnJvdy4KPgo+IFRoaXMgaXMgYmFzaWNhbGx5IHdoYXQncyBkZWNzcmli ZWQgaW4gdGhlIERSSTIgd2lraSBhdAo+IGh0dHA6Ly93aWtpLngub3JnL3dpa2kvRFJJMiwgcmln aHQ/CgpJdCdzIGEgc3RlcCB0b3dhcmRzIGl0LiAgVGhlIGNoYW5nZXMgSSdkIGxpa2UgdG8gbWVy Z2Ugbm93IGRvZXNuJ3QKcHVsbCBpbiBhbnkgbWVtb3J5IG1hbmFnZXIgaW50ZWdyYXRpb24sIGJ1 dCBpdCBkb2VzIGludHJvZHVjZSB0aGUgRFJJCmJyZWFrYWdlIHJlcXVpcmVkIHRvIG1vdmUgdG8g R0xYMS40LiAgVGhlIHJlYXNvbiB0aGF0IEknbSBwcm9wb3NpbmcgdG8KbWVyZ2UgdGhpcyBub3cg aXMgdGhhdCBJJ20gZmFpcmx5IHN1cmUgdGhhdCB3ZSBjYW4gZ2V0IGV2ZXJ5dGhpbmcgZWxzZQoo RFJNLCBYIHNlcnZlciwgYW5kIEREWCBkcml2ZXJzKSBwdWxsZWQgdG9nZXRoZXIgYmVmb3JlIHRo ZSBuZXh0IE1lc2EKcmVsZWFzZSBpcyB1cC4gIEluIG90aGVyIHdvcmRzLCB3ZSBvbmx5IGJyZWFr IGl0IHRoaXMgb25lIHRpbWUuCgo+IFRoZSBmaXJzdCB0aGluZyB0aGF0IGdyYWJzIG15IGF0dGVu dGlvbiBpcyB0aGUgZmFjdCB0aGF0IGZyb250IGNvbG9yCj4gYnVmZmVycyBhcmUgYWxsb2NhdGVk IGJ5IHRoZSBYIHNlcnZlciBidXQgYmFjay9kZXB0aC9zdGVuY2lsL2V0YyBidWZmZXJzCj4gYXJl IGFsbG9jYXRlZCBieSB0aGUgYXBwL0RSSSBjbGllbnQuCj4KPiBJZiB0d28gR0xYIGNsaWVudHMg cmVuZGVyIHRvIHRoZSBzYW1lIGRvdWJsZS1idWZmZXJlZCBHTFggd2luZG93LCBlYWNoCj4gaXMg Z29pbmcgdG8gaGF2ZSBhIGRpZmZlcmVudC9wcml2YXRlIGJhY2sgY29sb3IgYnVmZmVyLCByaWdo dD8gIFRoYXQKPiBkb2Vzbid0IHJlYWxseSBvYmV5IHRoZSBHTFggc3BlYy4gIFRoZSByZW5kZXJi dWZmZXJzIHdoaWNoIGNvbXBvc2UgYSBHTFgKPiBkcmF3YWJsZSBzaG91bGQgYmUgYWNjZXNzaWJs ZS9zaGFyZWQgYnkgYW55IG51bWJlciBvZiBzZXBhcmF0ZSBHTFgKPiBjbGllbnRzIChsaWtlIGFu IFggd2luZG93IGlzIHNoYXJlZCBieSBtdWx0aXBsZSBYIGNsaWVudHMpLgo+Cj4gW0FjdHVhbGx5 LCByZS1yZWFkaW5nIHRoZSB3aWtpIHBhcnQgYWJvdXQgc2VyaWFsIG51bWJlcnMsIGl0IHNvdW5k cyBsaWtlCj4gYSBHTFggZHJhd2FibGUncyByZW5kZXJidWZmZXJzIHdpbGwgYmUgc2hhcmVkLiAg TWF5YmUgdGhhdCBjb3VsZCBiZQo+IGNsYXJpZmllZD9dCgpZZXMsIHRoaXMgdXNlIGlzIGNvbnNp ZGVyZWQgaW4gdGhlIGRlc2lnbi4gIEEgR0xYIGRyYXdhYmxlICh3aW5kb3csCnBpeG1hcCBvciBw YnVmZmVyKSBoYXMgYW4gYXNzb2NpYXRlZCBkcm1fZHJhd2FibGVfdCBpbiB0aGUgRFJNLiAgV2hl bgp0aGUgRFJJIGRyaXZlciB3YW50cyB0byByZW5kZXIgdG8gYSBkcmF3YWJsZSBpdCBhc2tzIHRo ZSBYIHNlcnZlciBmb3IKdGhlIGRybV9kcmF3YWJsZV90IGZvciB0aGUgWCBkcmF3YWJsZSBhbmQg dGhlbiBhc2tzIHRoZSBEUk0gKHVzaW5nIGFuCmlvY3RsIEkgd2lsbCBhZGQgbGF0ZXIpIGFib3V0 IHRoZSBidWZmZXJzIGN1cnJlbnRseSBhc3NvY2lhdGVkIHdpdGgKdGhlIGRybV9kcmF3YWJsZV90 LiAgSWYgdGhlIGRyaXZlciBnZXRzIHRoZSBidWZmZXJzIGl0IG5lZWRzLCBpdCBjYW4KanVzdCBj cmVhdGUgdGhlIHJlbmRlciBidWZmZXJzIGFuZCB0aGVuIHN0YXJ0IHJlbmRlcmluZy4gIFRoaXMg aXMKdHlwaWNhbGx5IHRoZSBjYXNlIHdoZW4gc29tZSBvdGhlciBjbGllbnQgaXMgcmVuZGVyaW5n IHRvIHRoZSBkcmF3YWJsZQphbmQgaGFzIGFscmVhZHkgc2V0IHVwIHRoZSBidWZmZXJzLiAgT2Yg Y291cnNlLCB0aGF0IG90aGVyIGNsaWVudCBtYXkKbm90IGhhdmUgc2V0IHVwIGFsbCB0aGUgYnVm ZmVycyB0aGUgY2xpZW50IG5lZWRzIChtYXliZSBpdCBkb2Vzbid0IHVzZQphIGRlcHRoIGJ1ZmZl cikgb3IgbWF5YmUgdGhlIGNsaWVudCBpcyB0aGUgZmlyc3QgdG8gcmVuZGVyIHRvIHRoZQpkcmF3 YWJsZSwgaW4gd2hpY2ggY2FzZSB0aGUgY2xpZW50IG11c3QgYWxsb2NhdGUgYW5kIGF0dGFjaCB0 aGUKbWlzc2luZyBidWZmZXJzLgoKVGhlIHNlcmlhbCBudW1iZXIgbWVjaGFuaXNtIGlzIG5lY2Vz c2FyeSB0byBwcmV2ZW50IHRvIGNsaWVudHMgZnJvbQpyYWNpbmcgdG8gYXR0YWNoIGJ1ZmZlcnMu ICBTdXBwb3NlIHR3byBjbGllbnRzIHN0YXJ0IHJlbmRlcmluZyBhdCB0aGUKc2FtZSB0aW1lIGFu ZCBib3RoIGZpbmQgdGhhdCBubyBidWZmZXJzIGhhdmUgeWV0IGJlZW4gYXR0YWNoZWQuICBUaGV5 CndpbGwgYm90aCBnbyBhbmQgYWxsb2NhdGUgdGhlIHNldCB0aGV5IG5lZWQgYW5kIHRyeSB0byBh dHRhY2ggdGhlbS4KVGhlIGJ1ZmZlcnMgdGhhdCBvdmVybGFwIChzdXBwb3NlIHRoZXkgYm90aCBh bGxvY2F0ZSBhIGJhY2sgYnVmZmVyKQp3aWxsIGJlIHNldCB0d2ljZS4gIFRoZSBzZXJpYWwgbnVt YmVyIGxldHMgdGhlIGtlcm5lbCBrbm93IHRoYXQgdGhleQphcmUgYm90aCB0cnlpbmcgdG8gc2V0 IHRoZSBiYWNrIGJ1ZmZlciBmb3IgdGhlIHNhbWUgImluc3RhbmNlIiBvZiB0aGUKYXR0YWNoZWQg ZnJvbnQgYnVmZmVyLiAgT25seSBvbmUgYnVmZmVyIGNhbiBiZSBhdHRhY2hlZCBmb3IgZWFjaApp bmNyZW1lbnQgb2YgdGhlIHNlcmlhbCBudW1iZXIgYW5kIHRodXMgdGhlIGtlcm5lbCBjYW4gbGV0 IG9uZSBvZiB0aGUKY2xpZW50cyBrbm93IHRoYXQgdGhlIGJ1ZmZlciBpdCBwcm9wb3NlZCB3YXNu J3Qgc2V0LgoKPiBQcmlvciB0byBEUkkgInByaXZhdGUiIGJhY2sgYnVmZmVycyB3ZSBwcmV0dHkg bXVjaCBnb3QgdGhpcyBiZWhhdmlvdXIKPiBhdXRvbWF0aWNhbGx5ICh0aG91Z2gsIHNvZnR3YXJl LWFsbG9jYXRlZCBhY2N1bSBidWZmZXJzLCBmb3IgZXhhbXBsZSwKPiB3ZXJlIG5vdCBwcm9wZXJs eSBzaGFyYWJsZSkuCgpZdXAsIHRoZSBzaGFyZWQgYmFjayBidWZmZXJzIGRlc2lnbiBtYWRlIHRo aXMgZWFzeS4gIFdpdGggcHJpdmF0ZSBiYWNrCmJ1ZmZlcnMgaXQncyBhIGxpdHRsZSBtb3JlIHRy aWNreSBzaW5jZSB3ZSBuZWVkIG9uZSBwbGFjZSB0aGF0IHRyYWNrcwp0aGUgbWFwcGluZyBiZXR3 ZWVuIGEgZHJhd2FibGUgYW5kIHRoZSBhdHRhY2hlZCBhbmNpbGxhcnkgYnVmZmVycy4KVGhlIHBy b3RvdHlwZSBJIGRlbW9lZCBhdCBYRFMgdXNlZCB0aGUgRFJJIG1vZHVsZSBpbiB0aGUgc2VydmVy IGZvcgp0aGlzLCBidXQgd2Ugd2UgZGVjaWRlZCB0byBtb3ZlIGl0IHRvIERSTSBhcyBkZXNjcmli ZWQgYWJvdmUuCgo+IFN1cHBvc2UgYWxsIHRoZSByZW5kZXJidWZmZXJzIHdoaWNoIGNvbXBvc2Ug YSBHTFggZHJhd2FibGUgd2VyZQo+IGFsbG9jYXRlZCBhbmQgcmVzaXplZCBieSB0aGUgWCBzZXJ2 ZXIuICBUaGUgRFJJIGNsaWVudHMgd291bGQganVzdCBoYXZlCj4gcG9sbCBvciBjaGVjayB0aGUg ZHJhd2FibGUgc2l6ZSB3aGVuIGFwcHJvcHJpYXRlIGJ1dCB0aGV5IHdvdWxkbid0IGhhdmUKPiB0 byBhbGxvY2F0ZSB0aGVtLiAgSSBkb24ndCBrbm93IGlmIHlvdSd2ZSBnb25lIGRvd24gdGhpcyBy b2FkIGF0IGFsbC4KPiBUaGVyZSdzIHByb2JhYmx5ICJpbnRlcmVzdGluZyIgaXNzdWVzLgoKSSBo YWQgdGhpcyB3b3JraW5nIGF0IFhEUywgYW5kIGl0IGNhbiBiZSBtYWRlIHRvIHdvcmsuICBIb3dl dmVyLApjb21tdW5pY2F0aW5nIHRoZSBidWZmZXIgY2hhbmdlcyBhbmQgYXR0YWNobWVudHMgdGhy b3VnaCB0aGUga2VybmVsCmxldHMgdXMgZWxpbWluYXRlIHRoZSBTQVJFQSBjb21wbGV0ZWx5ICh3 ZSdyZSBkb2luZyBidWZmZXJzIHN3YXBzIGluCnRoZSBrZXJuZWwsIHNvIGNsaXByZWN0cyB3b24n dCBiZSBhbiBpc3N1ZSkuICBBbHNvLCBpZiB0aGUgWCBzZXJ2ZXIKbmVlZHMgdG8gYWxsb2NhdGUg YW5kIGF0dGFjaCB0aGUgYnVmZmVycywgd2UgaGF2ZSB0byBwYXNzIHRoZSBmYmNvbmZpZwpmcm9t IHRoZSBkcmkgY2xpZW50IGFsbCB0aGUgd2F5IHRvIHRoZSBYIHNlcnZlciAodGhyb3VnaCB0aGUg R0xYIGFuZApEUkkgbW9kdWxlcyBhbmQgdGhlbiB0byBERFggZHJpdmVyKSwgc28gdGhhdCB0aGUg RERYIGRyaXZlciBjYW4KYWxsb2NhdGUgdGhvc2UgYnVmZmVycy4gIFRoZSBvbmUgdGhpbmcgdGhh dCBjb252aW5jZWQgbWUgdG8gbW92ZSB0aGlzCnRvIHRoZSBrZXJuZWwsIHRob3VnaCwgd2FzIHRo YXQgd2UgYWxyZWFkeSBkbyBzd2FwIGJ1ZmZlcnMgaW4gdGhlCmtlcm5lbCB3aGVuIHN5bmNpbmcg dG8gdmJsYW5rLiAgSSB3YXMgdHJ5aW5nIHRvIGtlZXAgY2xpcCByZWN0cyBhbmQKYnVmZmVyIGF0 dGFjaG1lbnRzIG91dCBvZiB0aGUga2VybmVsIGJ5IGtlZXBpbmcgdGhlIGxvZ2ljIGluIHRoZSBY CnNlcnZlciBEUkkgbW9kdWxlLCBidXQgc2luY2Ugd2UndmUgYWxyZWFkeSBsZWFrZWQgY2xpcCBy ZWN0cyBpbnRvIERSTSwKd2UgbWlnaHQgYXMgd2VsbCB0cmFjayBhbmNpbGxhcnkgYnVmZmVyIGF0 YWNobWVudHMgYW5kIGRyb3AgdGhlIFNBUkVBLgoKPiBJJ2QgYmUgaW50ZXJlc3RlZCB0byBnZXQg eW91ciB0aG91Z2h0cyBvbiB0aGlzLgo+Cj4KPiBUaGUgc2Vjb25kIHRoaW5nIEknbSBjb25jZXJu ZWQgYWJvdXQgaXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBhbmQKPiB2ZXJzaW9uaW5nLiAgVG9k YXkgdGhlIE1lc2EgNy4xIGFuZCA3LjAuMSBicmFuY2hlcyBkZXBlbmQgb24gZGlmZmVyZW50Cj4g RFJNIGFuZCBERFggZHJpdmVyIHZlcnNpb25zLiAgSXQncyBxdWl0ZSBhIFBJVEEgdG8gd29yayB3 aXRoIGJvdGgKPiBicmFuY2hlcyBvbiBvbmUgc3lzdGVtLiAgSSdtIGFmcmFpZCBEUkkyIGlzIGdv aW5nIHRvIGJlIGFub3RoZXIgdmFyaWFibGUKPiB0byBjYXVzZSBzb21lIGhlYWRhY2hlcyAobm90 IGp1c3QgZm9yIG1lIGJ1dCBmb3IgdXNlcnMgd2hvIGRvbid0IGtub3cKPiB3aGljaCB2ZXJzaW9u cyBvZiB3aGljaCBwaWVjZXMgd29yayBvciBkb24ndCB3b3JrIHRvZ2V0aGVyKS4KPgo+IEl0IHNv dW5kcyBsaWtlIHlvdSd2ZSBwdXQgc29tZSB0aG91Z2h0IGludG8gdGhpcyBzbyBtYXliZSBpdCB3 b24ndCBiZQo+IHRoYXQgYmFkLiAgSSBndWVzcyBJJ2QganVzdCBzdWdnZXN0IHRoYXQgeW91IHRy eSB0byBtYWtlIHRoZSB0cmFuc2l0aW9uCj4gYXMgc21vb3RoIGFzIHBvc3NpYmxlIGFuZCB0cnkg dG8gYmUgZm9yd2FyZC1sb29raW5nIHRvIGF2b2lkIGFub3RoZXIKPiBsYXJnZSBBUEkgY2hhbmdl IGluIHRoZSBmdXR1cmUuICBBcmUgdGhlcmUgb3RoZXIgdGhpbmdzIG9uIHRoZSBob3Jpem9uCj4g dGhhdCdsbCBwcm9tcHQgRFJJMz8KClRoZSBpbnRlcmZhY2UgY2hhbmdlcyBJJ20gcHJvcG9zaW5n IGhlcmUgaGF2ZSBiZWVuIGluIHRoZSB3b3JrcyBzaW5jZQpBSUdMWCBsYW5kZWQsIGFuZCBJIGRp ZCBtb3N0IG9mIHRoZSB3b3JrIGFib3V0IGhhbGYgYSB5ZWFyIGFnby4gIEkndmUKYmVlbiBob2xk aW5nIGJhY2sgZnJvbSBtZXJnaW5nIGl0IHVudGlsIEkgaGF2ZSBhIHJ1bm5pbmcgR0xYMS40ICsK cmVkaXJlY3RlZCBkaXJlY3QgcmVuZGVyaW5nIHByb3RvdHlwZSB0aGF0IGRlbW9uc3RyYXRlIHRo YXQgdGhlCmludGVyZmFjZSBjaGFuZ2VzIHdpbGwgc3VwcG9ydCB0aGF0LiAgSSdtIGFsc28gaW50 cm9kdWNpbmcgYSBuZXcKZXh0ZW5zaW9uIG1lY2hhbmlzbSwgdGhhdCB3aWxsIGxldCB1cyBhZGQg YW5kIHBoYXNlIG91dCBuZXcgZXh0ZW5zaW9uCnRvIHRoZSBpbnRlcmZhY2UgbXVjaCBtb3JlIHNt b290aGx5IHRoYW4gYmVmb3JlLiAgRmluYWxseSwgSSBzcGVudAplbm91Z2ggdGltZSB0YWxraW5n IHRvIEtlaXRoIFcgYWJvdXQgR2FsbGl1bSBhbmQgaG93IHRoYXQgd2lsbCBhZmZlY3QKdGhpcyBw YXJ0IG9mIHRoZSBzdGFjaywgdGhhdCBJIGJlbGlldmUgdGhhdCB0aGVzZSB3aWxsIHdvcmsgd2Vs bCB0aGVyZQp0b28uICBUaGluayBvZiBpdCBhcyB0aGUgR2FsbGl1bSBEUkksIGlmIHlvdSB3aWxs IDopCgpUaGF0IHNhaWQsIEkgY2FuJ3QgZ3VhcmFudGVlIHRoYXQgd2UgaGF2ZW4ndCBvdmVybG9v a2VkIHNvbWV0aGluZyB0aGF0CndlJ2xsIGhhdmUgdG8gYWRkIGxhdGVyLiAgSG93ZXZlciwgdGhl IGJyZWFrIGlzIHJlcXVpcmVkLCBpZiB3ZSB3YW50CnRvIG1vdmUgdG8gR0xYIDEuNC4KCkhvcGUg dGhhdCBjbGVhcnMgaXQgdXAsCktyaXN0aWFuCg== |
From: Allen A. <ak...@po...> - 2007-10-11 22:09:43
|
On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote: | Suppose 2 clients render to the same backbuffer... The (rare) cases in which I've seen this used, the clients are aware of one another, and restrict their rendering to non-overlapping portions of the drawable. A "master" client is responsible for swap and clear. I believe the intent of the spec was to allow CPU-bound apps to make use of multiple processors. Rendering to a single drawable, rather than multiple drawables, allowed swap to be synchronized. I recall discussions about ways to coordinate multiple command streams so that rendering to overlapping areas of the drawable could be handled effectively, but I don't remember any apps that used such methods. Allen |
From: Brian P. <bri...@tu...> - 2007-10-11 22:13:26
|
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 |
From: Brian P. <bri...@tu...> - 2007-10-11 22:47:29
Attachments:
glxsnoop.png
|
I just commited this. usage: 1. start a GL demo 2. use 'xwininfo' to get the app's window ID 3. run 'glxsnoop <window id>' 4. press z/s/b/f to view the app's z, stencil, back, front buffer I tested with the 7.0.2 i915 DRI driver and it doesn't work, unfortunately. Nor will it work with the Xlib driver (obviously). With NVIDIA's driver it works as expected, mostly. Sometimes viewing the Z or stencil buffer results in a corrupted image (sample attached). Not sure if this is just a bug or I'm just getting lucky when it does work. -Brian |
From: <kr...@bi...> - 2007-10-11 22:53:26
|
On 10/11/07, Brian Paul <bri...@tu...> wrote: > Keith Whitwell wrote: ... > > 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. No worries, I'm only starting to push for this to get merged now and I've been working on this on and off for a while. As mentioned, I've not pushed it earlier because I didn't want to break the driver API until we could pull it all together. I do expect that the gallium work can land in a later release though, so that once we have the memory manager and the new dri interface working, we can do a mesa release. How does that sound? Kristian |
From: Keith W. <ke...@tu...> - 2007-10-11 22:39:44
|
Brian Paul wrote: > Keith Whitwell wrote: >> Brian Paul wrote: >>> Kristian H=F8gsberg 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=3Ddri2 >>>> >>>> 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 wit= h >>>> 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 f= or >>>> 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 ent= ry >>>> 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= =2E >>>> If the loader has an old style DRI/DRM available, it will look for t= he >>>> old entry point. >>>> >>>> I'll wait a day or so to let people chime in, but if I don't hear an= y >>>> "stop the press" type of comments, I'll merge it tomorrow. >>> >>> This is basically what's decsribed in the DRI2 wiki at=20 >>> 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=20 >>> buffers are allocated by the app/DRI client. >>> >>> If two GLX clients render to the same double-buffered GLX window,=20 >>> each is going to have a different/private back color buffer, right? = >>> That doesn't really obey the GLX spec. The renderbuffers which=20 >>> compose a GLX drawable should be accessible/shared by any number of=20 >>> separate GLX clients (like an X window is shared by multiple X client= s). >> >> 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=3D0, doing something straightforward like (clear, draw,=20 >> swapbuffers) there's nothing in the spec that says to me that they=20 >> actually have to have been rendering to the same surface in memory,=20 >> because the serialization could just be (clear-a, draw-a, swap-a,=20 >> clear-b, draw-b, swap-b) so that potentially only one client's=20 >> rendering ends up visible. >> >> So I would say that at least between a fullscreen clear and either=20 >> swap-buffers or some appropriate flush (glXWaitGL ??), we can treat=20 >> the rendering operations as atomic and have a lot of flexibility in=20 >> terms of how we schedule actual rendering and whether we actually=20 >> 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=20 >> state. >=20 > 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=20 > read the spec. Yes, but only if there was a flush-a in there somewhere, and even then=20 you'd need something to ensure that it didn't come out like: =09 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=20 normal for A and B to buffer up whole frame-worths of rendering in a=20 single DMA buffer, and not to fire that buffer until you get a flush.=20 Without the flushes and explicit signals, any ordering is possible as=20 long as it respects the local orderings inside A and B. >=20 >> 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=20 >> is emitting commands, and to know that it won't change size until it=20 >> is ready for it to is really crucial to building a solid driver. >=20 > Agreed. >=20 >=20 >> The trouble with sharing a backbuffer is what to do about the=20 >> situation where two clients end up with different ideas about what=20 >> size the buffer should be. >> >> So, if it is necessary to share backbuffers, then what I'm saying is=20 >> 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= =20 >> 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=20 >> actually think. >> >> 2) Alternate semantics where the X server allocates the buffers=20 >> but drivers just throw away frames when they find the buffer has=20 >> changed shape at the end of rendering. I'm sure this would be=20 >> nonconformant, at any rate it seems nasty. (i915 swz driver is forced= =20 >> 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=20 >> client on the older buffer calls swapbuffers -- I'm sure we can figure= =20 >> out what the correct behaviour should be. >=20 > I don't know the answers to this either. >=20 > 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=20 > other app's windows (Render SPU's render_to_app_window option). But in= =20 > that case, the owner of the window no longer renders into the window=20 > once Chromium takes over. I think the "VirualGL" utility might rely on= =20 > reading other client's GLX buffers, but I'd have to take a closer look.= >=20 > I'm just finishing up a new GLX test app that accesses another client's= =20 > 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=20 > window's back/stencil/z buffers. I used it a lot back in the day and=20 > always missed it when I left IRIX. I'll check it in soon. > I could probably quickly whip up another test that does coordinating=20 > rendering into one window from two processes. I could run it with=20 > NVIDIA's driver and see what happens there. Agreed, but also nv behaviour (whatever it may be) is not the only=20 option under the spec -- though if they break the spec that would be=20 interesting to know. I suspect they respect it when the window size=20 doesn't change, but I wonder what happens when two processes are=20 accessing a window which is subject to resize. Maybe we're examining the wrong spec here. My concerns are all about=20 what happens when the window changes size -- what does X tell us about=20 the contents of a window under those circumstances? Does the GLX spec=20 actually specify *anything* about this situation??? Keith |
From: Brian P. <bri...@tu...> - 2007-10-11 22:53:47
|
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 |
From: Keith P. <ke...@ke...> - 2007-10-12 00:44:33
|
On Thu, 2007-10-11 at 23:39 +0100, Keith Whitwell wrote: > Maybe we're examining the wrong spec here. My concerns are all about=20 > what happens when the window changes size -- what does X tell us about=20 > the contents of a window under those circumstances? Does the GLX spec=20 > actually specify *anything* about this situation??? As Brian said, X knows exactly when the window changes size, and the contents of the window at resize are well specified by the protocol. As X requests are always atomic, and executed as some shuffle of the request streams from all of the clients, there are no partial resize states to deal with. Clients can always know when drawing occurred before or after a resize as the resize events include the serial number of the most recently executed client request indicating when in the client's request stream the resize occurred. Making the resize asynchronous is a huge feature as it means applications often end up repainting less than once per resize as you reshape the window with the window manager. It sounds like the DRM needs to have an event queue for the X server to deliver resize evens into that is outside the X protocol (and hence not subject to the whims of the application). I suspect the DRI extension will need a new request that causes the X server to post events to the DRM module. Windows always contain their background in areas where expose events are delivered (again, the request serialization means this is always well defined in time). Backgrounds can consist of a single pixel value or an image to be tiled into the window, or they can be left as garbage (background None). This latter mode is often used to avoid flashing on the screen, but the actual contents of the window are not defined by the core protocol to be the parent contents in all cases. The Composite extension stands on its head to make the parent contents visible though, so I suppose we now have defined these contents as the parent contents in all cases. --=20 kei...@in... |
From: Keith W. <ke...@tu...> - 2007-10-11 23:08:19
|
Allen Akin wrote: > On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote: > | Suppose 2 clients render to the same backbuffer... > > The (rare) cases in which I've seen this used, the clients are aware of > one another, and restrict their rendering to non-overlapping portions of > the drawable. A "master" client is responsible for swap and clear. > > I believe the intent of the spec was to allow CPU-bound apps to make use > of multiple processors. Rendering to a single drawable, rather than > multiple drawables, allowed swap to be synchronized. > > I recall discussions about ways to coordinate multiple command streams > so that rendering to overlapping areas of the drawable could be handled > effectively, but I don't remember any apps that used such methods. Allen, Just to clarify, would things look a bit like this: Master: clear, glFlush, signal slaves somehow Slave0..n: wait for signal, don't clear, just draw triangles glFlush signal master Master: wait for all slaves glXSwapBuffers This is fairly sensible and clearly requires a shared buffer. It's also quite a controlled situation that sidesteps some of the questions about what happens when two clients are issuing swapbuffers willy-nilly on the same drawable at the same time as the user is frantically resizing it... Keith |
From: Keith W. <ke...@tu...> - 2007-10-11 23:19:35
|
Kristian H=F8gsberg wrote: > On 10/11/07, Keith Whitwell <ke...@tu...> wrote: >> Brian Paul wrote: > ... >>> If two GLX clients render to the same double-buffered GLX window, eac= h >>> 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=3D0, doing something straightforward like (clear, draw, swapbuffe= rs) >> 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 visibl= e. >=20 > 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. >=20 > ... >> 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. >=20 > 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. Yes, there are a few places, but they are very few. Basically I think=20 it is possible to cut a rendering stream up into chunks which are=20 effectively atomic. Drivers do this all the time anyway - just by=20 building a dma buffer that is then submitted atomically to hardware for=20 processing. It isn't too hard to figure out where the boundaries of these regions=20 are - if we think about a driver with effectively infinite dma space,=20 then such a driver only flushes when required to satisfy requirements=20 placed on it by the spec. I also believe that the only sane time to check the size of the=20 destination drawable is when the driver is *entering* such an atomic=20 region (let's call it a scene). Swapbuffers terminates a scene, it doesn't really start the next one -=20 that doesn't happen until actual rendering starts. I would even say=20 that fullscreen clears don't start a scene, but that's another story... The things that terminate a scene are: - swapbuffers - readpixels and similar - maybe glFlush() - though I'm sometimes naughty and no-op it for=20 backbuffer rendering. Basically any API-generated event that implies a flush. Internally=20 generated events, like running out of some resource and having to fire=20 buffers to recover generally don't count. >> 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 driv= ers but >> some deviation from GLX specs - maybe less deviation than we actually = think. >> >> 2) Alternate semantics where the X server allocates the buffer= s 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 cli= ent >> 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. >=20 > 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. >=20 > 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. OK, sounds good Kristian. Keith |
From: Keith P. <ke...@ke...> - 2007-10-12 00:51:27
|
On Fri, 2007-10-12 at 00:19 +0100, Keith Whitwell wrote: > Basically any API-generated event that implies a flush. Internally=20 > generated events, like running out of some resource and having to fire=20 > buffers to recover generally don't count. If I understand this, then the only time you'll check for window resize is just before the next drawing occurs after one of these events. That makes a huge amount of sense to me, and limits polling to once per scene, instead of once per batchbuffer. And, we do all of this polling through the DRM, which would allow things other than the X server to send resize events for non-X buffers. --=20 kei...@in... |
From: Allen A. <ak...@po...> - 2007-10-11 23:34:36
|
On Fri, Oct 12, 2007 at 12:08:09AM +0100, Keith Whitwell wrote: | Just to clarify, would things look a bit like this: | | Master: | clear, | glFlush, | signal slaves somehow | | Slave0..n: | wait for signal, | don't clear, just draw triangles | glFlush | signal master | | Master: | wait for all slaves | glXSwapBuffers Yes, more or less. As I look at it now, I wonder if the master really did a clear, or if the slaves simply drew background polygons over their respective regions. It's also possible that the swap guarantees a flush for commands queued by all the slaves, but I'm unsure of that without checking the spec. | This is fairly sensible and clearly requires a shared buffer. It's also | quite a controlled situation that sidesteps some of the questions about | what happens when two clients are issuing swapbuffers willy-nilly on the | same drawable at the same time as the user is frantically resizing it... Right. Allen |
From: Brian P. <bri...@tu...> - 2007-10-12 00:38:43
Attachments:
corender.png
|
I've checked in a new GLX test for rendering into one GLX window by two processes. See comments in progs/xdemos/corender.c for instructions. Two interlocking tori are drawn. The first process draws a red one, the second process draws a blue one. I'm getting mixed results. With an old GeForce3 series card it seems to work perfectly. With a GeForce 7300 card there's rendering glitches. The blue torus isn't depth-buffered correctly. But if I insert an extra glClear(GL_DEPTH_BUFFER_BIT) it works except for an occasional glitch. Pretty weird - the second clear shouldn't do what it does. See attached image. In both cases, rapid window resizes causes lots of window flickering but no noticable distortion of the rendering otherwise. -Brian |
From: Michel <mi...@tu...> - 2007-10-12 09:09:20
|
On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: > On 10/11/07, Keith Whitwell <ke...@tu...> wrote: > > > 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. I agree, it looks like this can provide the benefits of shared drawable-private renderbuffers (support for cooperative rendering schemes, no waste of renderbuffer resources) without compromising the general benefits of private renderbuffers. > 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. Meanwhile though, these changes already drop support for existing loaders, right? That's rather inconvenient for AIGLX, not so much for libGL. I don't suppose it would be reasonably possible to retain support for __driCreateNewScreen_20050727, at least until there's an xserver release that supports the new one? If not, I wonder if it might be worth holding off a bit longer until the changes will provide real benefits such as new GLX features, as otherwise they would seem to require inter-component lockstep for little gain. Apart from that, the changes look good to me, with one exception: b068af2f3b890bec26a186e9d0bdd3d44c17cd4d ('Key drm_i915_flip_t typedef off of the ioctl #define instead.'). DRM_IOCTL_I915_FLIP was already defined before drm_i915_flip_t and friends were introduced. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Keith W. <ke...@tu...> - 2007-10-12 09:19:50
|
Michel D=E4nzer wrote: > On Thu, 2007-10-11 at 18:44 -0400, Kristian H=F8gsberg wrote: >> On 10/11/07, Keith Whitwell <ke...@tu...> wrote: >> >>> 3) Share buffers with a reference counting scheme. When a cl= ient >>> 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 figur= e >>> out what the correct behaviour should be. >> 3) Sounds like the best solution and it's basically what I'm >> proposing. >=20 > I agree, it looks like this can provide the benefits of shared > drawable-private renderbuffers (support for cooperative rendering > schemes, no waste of renderbuffer resources) without compromising the > general benefits of private renderbuffers. Yes, I'm just interested to understand what happens when one of the=20 clients on the old, orphaned buffer calls swapbuffers... All the=20 buffers should be swapped, right? Large and small? How does that work? If the answer is that we just do the swap on the largest buffer, then=20 you have to wonder what the point of keeping the smaller ones around is? IE - if there are multiple clients rendering to a buffer and that buffer = is resized bigger, the first client to notice will allocate larger=20 backbuffers and down-reference the smaller ones. The other clients keep = rendering to the smaller ones. The next time swapbuffers is called,=20 what happens to the results of the rendering on the smaller buffers? Note that this question only comes up in terms of multiple clients. For = a single client the behaviour is basically the same as what we're doing=20 in the client-side private-backbuffers code right now - the single=20 client will notice there has been a resize and organize for new, larger=20 buffers to be allocated. From that point on it will draw into the=20 larger ones. So the question is - how much effort do we want to put into the case=20 where there are multiple clients PLUS buffer resizes. Multiple clients=20 is a rare case in itself, and resizes are a transient varient on a rare=20 case. Also just what can we gain by putting effort into that case -- do = we get a behaviour that is actually any more sensible than just thowing=20 away the rendering of the additional clients until they get themselves=20 sorted out with the new buffer size??? Keith |
From: <kr...@bi...> - 2007-10-13 03:32:23
|
On 10/12/07, Keith Whitwell <ke...@tu...> wrote: ... > So the question is - how much effort do we want to put into the case > where there are multiple clients PLUS buffer resizes. Multiple clients > is a rare case in itself, and resizes are a transient varient on a rare > case. Also just what can we gain by putting effort into that case -- do > we get a behaviour that is actually any more sensible than just thowing > away the rendering of the additional clients until they get themselves > sorted out with the new buffer size??? As long as the app can render the final frame correctly based on the last resize event it sees, I think we're fine. We can't guarantee that intermediate frames will be fully consistent Core X rendering has this problem too to some extent: an application sees a resize event, sends a series of rendering requests based on the new size. The stream of requests isn't atomic with respect to subsequent resizing and this can result in, if not undefined, at least undesired results. To get consistent resizing, the windows manager and application have to implement a higher level protocol where the windows manager coordinate resizing with the application so that it doesn't resize again before the application has finished rendering the previous layout. Both compiz and metacity already implement this in cooperation with gtk+, and the same protocol can be used for opengl that care about consistent resizing. So in short, we're not introducing a new problem here, and it's a situation that can has has been solved. Kristian |
From: Michel <mi...@tu...> - 2007-10-12 09:32:05
|
On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: > >> On 10/11/07, Keith Whitwell <ke...@tu...> wrote: > >> > >>> 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. > > > > I agree, it looks like this can provide the benefits of shared > > drawable-private renderbuffers (support for cooperative rendering > > schemes, no waste of renderbuffer resources) without compromising the > > general benefits of private renderbuffers. > > Yes, I'm just interested to understand what happens when one of the > clients on the old, orphaned buffer calls swapbuffers... All the > buffers should be swapped, right? Large and small? How does that work? > > If the answer is that we just do the swap on the largest buffer, then > you have to wonder what the point of keeping the smaller ones around > is? To make 3D drivers nice and simple by not having to deal with fun stuff like cliprects? :) Seriously though, as I understand Kristian's planned scheme, all buffer swaps will be done by the DRM, and I presume it'll only take the currently registered back renderbuffer into account, so the contents of any previous back renderbuffers will be lost. I think that's fine, and should address your concerns? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Keith W. <ke...@tu...> - 2007-10-12 09:37:11
|
Michel D=E4nzer wrote: > On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: >> Michel D=E4nzer wrote: >>> On Thu, 2007-10-11 at 18:44 -0400, Kristian H=F8gsberg wrote: >>>> On 10/11/07, Keith Whitwell <ke...@tu...> wrote: >>>> >>>>> 3) Share buffers with a reference counting scheme. When a = client >>>>> notices the buffer needs a resize, do the resize and adjust refcoun= ts - >>>>> other clients continue with the older buffer. What happens when a >>>>> client on the older buffer calls swapbuffers -- I'm sure we can fig= ure >>>>> out what the correct behaviour should be. >>>> 3) Sounds like the best solution and it's basically what I'm >>>> proposing. >>> I agree, it looks like this can provide the benefits of shared >>> drawable-private renderbuffers (support for cooperative rendering >>> schemes, no waste of renderbuffer resources) without compromising the= >>> general benefits of private renderbuffers. >> Yes, I'm just interested to understand what happens when one of the=20 >> clients on the old, orphaned buffer calls swapbuffers... All the=20 >> buffers should be swapped, right? Large and small? How does that work= ? >> >> If the answer is that we just do the swap on the largest buffer, then = >> you have to wonder what the point of keeping the smaller ones around >> is? >=20 > To make 3D drivers nice and simple by not having to deal with fun stuff= > like cliprects? :) Understood. I'm thinking about a further simplification - rather than=20 keep the old buffers around after the first client requests a resize,=20 just free them. If/when other clients submit commands targeting the=20 old-sized buffers, throw those commands away. > Seriously though, as I understand Kristian's planned scheme, all buffer= > swaps will be done by the DRM, and I presume it'll only take the > currently registered back renderbuffer into account, so the contents of= > any previous back renderbuffers will be lost. I think that's fine, and > should address your concerns? See above -- if the contents of the previous back renderbuffers are=20 going to be lost, what is the point in keeping those buffers around? Or = doing any further rendering into them? Keith |
From: Michel <mi...@tu...> - 2007-10-13 11:33:08
|
On Fri, 2007-10-12 at 10:36 +0100, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: > >> Michel Dänzer wrote: > >>> On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: > >>>> On 10/11/07, Keith Whitwell <ke...@tu...> wrote: > >>>> > >>>>> 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. > >>> I agree, it looks like this can provide the benefits of shared > >>> drawable-private renderbuffers (support for cooperative rendering > >>> schemes, no waste of renderbuffer resources) without compromising the > >>> general benefits of private renderbuffers. > >> Yes, I'm just interested to understand what happens when one of the > >> clients on the old, orphaned buffer calls swapbuffers... All the > >> buffers should be swapped, right? Large and small? How does that work? > >> > >> If the answer is that we just do the swap on the largest buffer, then > >> you have to wonder what the point of keeping the smaller ones around > >> is? > > > > To make 3D drivers nice and simple by not having to deal with fun stuff > > like cliprects? :) > > Understood. I'm thinking about a further simplification - rather than > keep the old buffers around after the first client requests a resize, > just free them. I see, but how would that work? If it hasn't happened yet, the plan seems to be to make BOs strictly reference counted. No matter who creates the new renderbuffers, some clients may keep the old ones referenced until they catch up. If it's still somehow possible to avoid wasting resources in this case, that would be nice, but otherwise it seems like too much of a corner case to worry about. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: <kr...@bi...> - 2007-10-12 15:53:57
|
T24gMTAvMTIvMDcsIE1pY2hlbCBEw6RuemVyIDxtaWNoZWxAdHVuZ3N0ZW5ncmFwaGljcy5jb20+ IHdyb3RlOgouLi4KPiA+IFRoZSBEUkkgZHJpdmVyIGludGVyZmFjZSBjaGFuZ2VzIEknbSBwcm9w b3NpbmcgaGVyZSBzaG91bGQgbm90IGJlCj4gPiBhZmZlY3RlZCBieSB0aGVzZSBpc3N1ZXMgdGhv dWdoLiAgRGV0ZWN0aW5nIHRoYXQgdGhlIGJ1ZmZlcnMgY2hhbmdlZAo+ID4gYW5kIGFsbG9jYXRp bmcgYW5kIGF0dGFjaGluZyBuZXcgb25lcyBpcyBlbnRpcmVseSBiZXR3ZWVuIHRoZSBEUkkKPiA+ IGRyaXZlciBhbmQgdGhlIERSTS4gIFdoZW4gd2UncmUgcmVhZHkgdG8gYWRkIHRoZSBUVE0gZnVu Y3Rpb25hbGl0eSB0bwo+ID4gYSBkcml2ZXIgd2UgYWRkIHRoZSBuZXcgY3JlYXRlTmV3U2NyZWVu IGVudHJ5IHBvaW50IEkgbWVudGlvbmVkIGFuZAo+ID4gdGhhdCdzIGFsbCB3ZSBuZWVkIHRvIGNo YW5nZS4gIFNvLCBpbiBvdGhlciB3b3JkcywgSSBiZWxpZXZlIHdlIGNhbgo+ID4gbW92ZSBmb3J3 YXJkIHdpdGggdGhpcyBtZXJnZSB3aGlsZSB3ZSBmaWd1cmUgb3V0IHRoZSBzZW1hbnRpY3Mgb2Yg dGhlCj4gPiByZXNpemluZy13aGlsZS1yZW5kZXJpbmcgY2FzZS4KPgo+IE1lYW53aGlsZSB0aG91 Z2gsIHRoZXNlIGNoYW5nZXMgYWxyZWFkeSBkcm9wIHN1cHBvcnQgZm9yIGV4aXN0aW5nCj4gbG9h ZGVycywgcmlnaHQ/IFRoYXQncyByYXRoZXIgaW5jb252ZW5pZW50IGZvciBBSUdMWCwgbm90IHNv IG11Y2ggZm9yCj4gbGliR0wuIEkgZG9uJ3Qgc3VwcG9zZSBpdCB3b3VsZCBiZSByZWFzb25hYmx5 IHBvc3NpYmxlIHRvIHJldGFpbiBzdXBwb3J0Cj4gZm9yIF9fZHJpQ3JlYXRlTmV3U2NyZWVuXzIw MDUwNzI3LCBhdCBsZWFzdCB1bnRpbCB0aGVyZSdzIGFuIHhzZXJ2ZXIKPiByZWxlYXNlIHRoYXQg c3VwcG9ydHMgdGhlIG5ldyBvbmU/IElmIG5vdCwgSSB3b25kZXIgaWYgaXQgbWlnaHQgYmUgd29y dGgKPiBob2xkaW5nIG9mZiBhIGJpdCBsb25nZXIgdW50aWwgdGhlIGNoYW5nZXMgd2lsbCBwcm92 aWRlIHJlYWwgYmVuZWZpdHMKPiBzdWNoIGFzIG5ldyBHTFggZmVhdHVyZXMsIGFzIG90aGVyd2lz ZSB0aGV5IHdvdWxkIHNlZW0gdG8gcmVxdWlyZQo+IGludGVyLWNvbXBvbmVudCBsb2Nrc3RlcCBm b3IgbGl0dGxlIGdhaW4uCgpUaGV5IGRvIGRyb3Agc3VwcG9ydCwgeWVzLCBidXQgb2YgY291cnNl LCBJJ20gY29tbWl0dGluZyBhIHNlcmllcyBvZiBYCnNlcnZlciBwYXRjaGVzIGFsb25nIHdpdGgg dGhpcyB0byBsZXQgQUlHTFggbG9hZCB0aGUgbmV3IGRyaXZlciBBUEkuClRoaXMgbWVhbnMgdGhh dCB5b3UgY2FuJ3QgbG9hZCBhIGdpdCBkcmkgZHJpdmVyIHdpdGggYW55IHJlbGVhc2VkIFgKc2Vy dmVyLCB3aGljaCBpcyB0aGUgaW5jb252ZW5pZW5jZSB5b3UncmUgcmVmZXJyaW5nIHRvIEkgZ3Vl c3MuICBJIGRvCnRoaW5rIGl0J3Mgd29ydGggbW92aW5nIGZvcndhcmQgd2l0aCB0aGlzIHRob3Vn aC4gIFBlcnNvbmFsbHksIEkgZ2V0CnRoZXNlIHBhdGNoZXMgb2ZmIG9mIG15IHBsYXRlIGFuZCBj YW4gZm9jdXMgb24gdGhlIG5leHQgc3RlcHMuICBXZSBnZXQKdGhlIHBhdGNoZXMgdXBzdHJlYW0g d2hpY2ggd2lsbCBnZXQgdGhlbSB0ZXN0ZWQsIGFuZCBJIHRoaW5rIHRoaXMgaXMKaW1wb3J0YW50 LCBzaW5jZSB0aGVyZSdzIGEgbG90IG1vcmUgd29yayBpbiB0aGUgcGlwZWxpbmUgZnJvbQpldmVy eWJvZHksIHNvIGFueSBlYXJseSB0ZXN0aW5nIHdlIGNhbiBkbyBpcyB2ZXJ5IG11Y2ggd29ydGgg aXQuCkZpbmFsbHksIGFsb25nIHdpdGggdGhlIFggc2VydmVyIHBhdGNoZXMsIHRoaXMgZG9lcyBs YW5kIG5ldyBmZWF0dXJlcy4KIFdpdGggdGhlc2UgcGF0Y2hlcyBJIGNhbiBsYW5kIHRoZSBYIHNl cnZlciB3b3JrIHRvIGVuYWJsZSBHTFggMS40CnN1cHBvcnQgYW5kIHRoZSB2aXN1YWwgY2xlYW51 cCwgd2UganVzdCB3b250IGJlIGFibGUgdG8gYWR2ZXJ0aXNlIGFueQpHTFhQaXhtYXAgb3IgR0xY UGJ1ZmZlciBjYXBhYmxlIGZiY29uZmlncyB5ZXQuCgo+IEFwYXJ0IGZyb20gdGhhdCwgdGhlIGNo YW5nZXMgbG9vayBnb29kIHRvIG1lLCB3aXRoIG9uZSBleGNlcHRpb246Cj4gYjA2OGFmMmYzYjg5 MGJlYzI2YTE4NmU5ZDBiZGQzZDQ0YzE3Y2Q0ZCAoJ0tleSBkcm1faTkxNV9mbGlwX3QgdHlwZWRl Zgo+IG9mZiBvZiB0aGUgaW9jdGwgI2RlZmluZSBpbnN0ZWFkLicpLiBEUk1fSU9DVExfSTkxNV9G TElQIHdhcyBhbHJlYWR5Cj4gZGVmaW5lZCBiZWZvcmUgZHJtX2k5MTVfZmxpcF90IGFuZCBmcmll bmRzIHdlcmUgaW50cm9kdWNlZC4KCll1cCwgbXkgYmFkLCBJIGRpZG4ndCBpbnN0YWxsIHRoZSBs aWJkcm0gcGtnLWNvbmZpZyBmaWxlLgoKY2hlZXJzLApLcmlzdGlhbgo= |
From: Michel <mi...@tu...> - 2007-10-12 15:57:38
|
On Fri, 2007-10-12 at 11:53 -0400, Kristian Høgsberg wrote: > > Finally, along with the X server patches, this does land new features. > With these patches I can land the X server work to enable GLX 1.4 > support and the visual cleanup, we just wont be able to advertise any > GLXPixmap or GLXPbuffer capable fbconfigs yet. Okay, that makes sense then. Thanks for clarifying this. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |