Hi, I about to take of for the holidays, but I wanted to give a heads up on how DRI2 is progressing and the direction I'm taking. The dri2 branches in my personal repos for drm, mesa, xserver and xf86-video-intel has the work. As it is, I can run glxgears under DRI2, though resizing the window breaks it right now. And only AIGLX works, since I haven't done DRI2 protocol. Oh well.
What I'm doing here lets us have both the old XF86DRI and the DRI2 code paths in the xserver, the DDX drivers and in mesa simultaneously, and the choice between the two is done in the DDX driver at startup, or you can compile in only one or the other. Right now I don't expect compiling just one of XF86DRI or DRI2 to work, but that's just because I haven't tried that yet. Ok, with all the caveats out of the way, let me just give a quick overview of the design that I've chosen. What I've come to realize is that there is many ways you can do this: clip rects in the kernel or not, swap buffer in the X server, kernel or DRI client, allocating back buffers in the X server or DRI client etc. But at the end of the day, I don't see a clear winning combination: all these choices have advantages and drawbacks, and everything else being equal, I've tried to design for these goals: - keep the kernel part simple, i.e. no cliprect or swap buffers there - provide a clean break to get rid of the XF86DRI legacy while retaining ABI - keep the lock for now, but provide a path towards lockless So what we have now is a new small DRI2 X module/extension that hooks pScreen->ClipNotify and pScreen->HandleExposures to track window movement, redirection and cliprect changes. The DDX driver opens the drm fd on its own and checks version and whatever other chipset specific setup it needs and then passes the fd to DRI2ScreenInit. DRI2 uses a buffer object based sarea, that is composed of a collection of sarea blocks, each of which have a common header identifying the block and specifying the size. The DDX driver can put it's own blocks there if necessary, and that is how locking works. Core DRI2 doesn't know about the DRM lock, so the DDX driver has to put a DRILock block in the sarea if it needs one and implement locking itself. So for the intel driver this means that we can now push the lock into the EXA callbacks and AIGLX with DRI2 no longer need the crazy lock-juggling. Longer term, we want to get rid of the lock entirely, but it's something I'd like to do in a later step. We have the big parts of the lock-less puzzle in place with the DRM memory manager and the super ioctl, but there is still a lot of places in the DDX driver that holds the lock for various reasons (mode setting, ring buffer access, vt switching). The devil certainly seems to be in the details, but by pushing the lock into the DDX driver, it's now a DDX decision and we can drop the lock in the near future without leaving ugly API scars. The DRI2 sarea also changes the drawable timestamp mechanism. Instead of the fixed size drawable table, I'm using the ring buffer design I outlined at XDS in Cambridge. The ring buffer is another block in the sarea and is written to only by the X server. The server post events here to describe changes in cliprects, window position and attached buffers. Each DRI2 client maintains its own tail pointer and reads out events as it needs them. One tricky detail about this is that when windows are moved, the DRI2 X server module must update the ring buffer head pointer atomically with posting the batch buffer to copy window contents. This complication is inherent in the way the X server moves windows, and will not go away if we were to move cliprects to the kernel. Finally, on the mesa side, the DRI drivers get a new entry point that the loader must call if it wants to use the DRI driver in DRI2 mode. In this mode the DRI driver avoids all the static buffers and looks for buffer information in the event ring buffer and allocates private back buffers as needed. I don't expect the patches to work for anybody at this stage (except, maybe if you have a G33), I'm in the process of cleaning up the code and working out the corner cases now. The xf86-video-intel patch applies on top the intel-batchbuffer branch, and the mesa patch currently conflicts with mesa mater. Oh, and ignore the I830* calls in the DRI2 module :) But even so, they show the overall direction and I'm interested feedback on the approach. cheers, Kristian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
