On 10/11/07, Brian Paul <[EMAIL PROTECTED]> 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?
It's a step towards it. The changes I'd like to merge now doesn't pull in any memory manager integration, but it does introduce the DRI breakage required to move to GLX1.4. The reason that I'm proposing to merge this now is that I'm fairly sure that we can get everything else (DRM, X server, and DDX drivers) pulled together before the next Mesa release is up. In other words, we only break it this one time. > 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?] Yes, this use is considered in the design. A GLX drawable (window, pixmap or pbuffer) has an associated drm_drawable_t in the DRM. When the DRI driver wants to render to a drawable it asks the X server for the drm_drawable_t for the X drawable and then asks the DRM (using an ioctl I will add later) about the buffers currently associated with the drm_drawable_t. If the driver gets the buffers it needs, it can just create the render buffers and then start rendering. This is typically the case when some other client is rendering to the drawable and has already set up the buffers. Of course, that other client may not have set up all the buffers the client needs (maybe it doesn't use a depth buffer) or maybe the client is the first to render to the drawable, in which case the client must allocate and attach the missing buffers. The serial number mechanism is necessary to prevent to clients from racing to attach buffers. Suppose two clients start rendering at the same time and both find that no buffers have yet been attached. They will both go and allocate the set they need and try to attach them. The buffers that overlap (suppose they both allocate a back buffer) will be set twice. The serial number lets the kernel know that they are both trying to set the back buffer for the same "instance" of the attached front buffer. Only one buffer can be attached for each increment of the serial number and thus the kernel can let one of the clients know that the buffer it proposed wasn't set. > Prior to DRI "private" back buffers we pretty much got this behaviour > automatically (though, software-allocated accum buffers, for example, > were not properly sharable). Yup, the shared back buffers design made this easy. With private back buffers it's a little more tricky since we need one place that tracks the mapping between a drawable and the attached ancillary buffers. The prototype I demoed at XDS used the DRI module in the server for this, but we we decided to move it to DRM as described above. > 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 had this working at XDS, and it can be made to work. However, communicating the buffer changes and attachments through the kernel lets us eliminate the SAREA completely (we're doing buffers swaps in the kernel, so cliprects won't be an issue). Also, if the X server needs to allocate and attach the buffers, we have to pass the fbconfig from the dri client all the way to the X server (through the GLX and DRI modules and then to DDX driver), so that the DDX driver can allocate those buffers. The one thing that convinced me to move this to the kernel, though, was that we already do swap buffers in the kernel when syncing to vblank. I was trying to keep clip rects and buffer attachments out of the kernel by keeping the logic in the X server DRI module, but since we've already leaked clip rects into DRM, we might as well track ancillary buffer atachments and drop the SAREA. > 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? The interface changes I'm proposing here have been in the works since AIGLX landed, and I did most of the work about half a year ago. I've been holding back from merging it until I have a running GLX1.4 + redirected direct rendering prototype that demonstrate that the interface changes will support that. I'm also introducing a new extension mechanism, that will let us add and phase out new extension to the interface much more smoothly than before. Finally, I spent enough time talking to Keith W about Gallium and how that will affect this part of the stack, that I believe that these will work well there too. Think of it as the Gallium DRI, if you will :) That said, I can't guarantee that we haven't overlooked something that we'll have to add later. However, the break is required, if we want to move to GLX 1.4. Hope that clears it up, Kristian ------------------------------------------------------------------------- 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
