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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
