On Dec 27, 2007 1:48 AM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > On Fri, 21 Dec 2007 16:59:11 -0500 > "Kristian Høgsberg" <[EMAIL PROTECTED]> wrote: > > > 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 > > I quickly looked at the code, so i might overlooked it and missed > few points, sorry if so. My concern is how front buffer (ie framebuffer > where the mesa driver have to blit the window as my guess is that > right now this is mesa driver who do that) is signaled to mesa.
Yes, mesa still does the blit to the front buffer. The way the X server communicate changes in the attached front buffer is by posting a buffer attach event in the event buffer. This happens at drawable creation time, when a window goes from direct to redirected or the other way, and when the front buffer is resized. > So is there one event ring buffer per client or glxcontext (i guess > i myself don't see clearly if there is a difference btw this two > things :)). Or is there an event ring buffer for all client/glxcontext. There is one per X server, which seems to be a good trade-off between memory usage and performance. It's not a high frequency channel anyway. > In first case i guess the first things the server post in the event > ring is the framebuffer informations (like how to get framebuffer bo > handle, shared zbuffer, ...). The X server allocates the front buffer and posts it in the event buffer. For non-redirected windows this is just the X server front buffer, for redirected windows it's the off-screen backing pixmap. Mesa is responsible for allocating the back buffers it needs and then telling the X server about them. > In the second case is there a mecanism for the driver to ask the server > to repost informations on the framebuffer (shared, zbuffer, shared ...) ? There will be, but it's not in the code. There will be a "ping" request to say "please repost info about this drm_drawable_t", which causes the X server to re-emit all state for that drawable in the event buffer. > In both case i think mesa part should also be ready to update its view > of where things should be blitted (ie being able to update its view of > how big and what is the bo handle of the framebuffer where it should > perform the blit). Yup, all that is in the code right now. Take a look at __driParseEvents() in common/dri_util.c. > Side question of this what about fullscreen glapp, should their frontbuffer > become the framebuffer ? My understanding being that each client got > their private front&back(if double buffered) which is then blit to the > framebuffer. I guess for fullscreen app we might want being able to give > full gpu juice and avoid the blit btw the front and framebuffer. Only the back buffers are private, the front buffer is shared and blitting to it is governed by the clip rects. So for a non-redirected full-screen app, the X server framebuffer is the mesa front buffer. > Others question what happen if the ring event buffer is full ie the > client/glxcontext is slow at reading it or is buggy and don't read > it anymore. Should this context get kill for not being responsive > maybe such case is already falling down into some X rules. The X server doesn't block on slow readers, it just overwrites the data. Each client has its own tail pointer into the ring buffer and can catch up with the X servers head point whenever they want. If they wait too long though, the X server will get ahead of them and overwrite data that they hadn't yet read. The clients will be able to detect this though and request (using the ping request described above) that the X server re-posts info about the drawable they're interested in. > Hope i am not asking trivial and already solved issues :) Nope, good questions about all the corner cases - I think I have thought through them all and that the event buffer design will work out. 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
