Hi all, I've been working on the DRI2 implementation recently and I'm starting to get a little confused, so I figured I'd throw a couple of questions out to the list. First of, I wrote up this summary shortly after XD
http://wiki.x.org/wiki/DRI2 which upon re-reading is still pretty much up to date with what I'm trying to do. The buzzword summary from the page has * Lockless * Always private back buffers * No clip rects in DRI driver * No DDX driver part * Minimal X server part * Swap buffer and clip rects in kernel * No SAREA I've implemented the DRI2 xserver module (http://cgit.freedesktop.org/~krh/xserver/log/?h=dri2) and the new drm ioctls that is uses (http://cgit.freedesktop.org/~krh/drm/log/?h=dri2). I did the DDX part for the intel driver and DRI2 initialization consists of doing drmOpen (this is now up to the DDX driver), initialize the memory manager and use it to allocate stuff and then call DRI2ScreenInit(), passing in pScreen and the file descriptor. Basically, all of i830_dri.c isn't used in this mode. It's all delightfully simple, but I'm starting to reconsider whether the "lockless" bullet point is realistic. Note, the drawable lock is gone, we always render to private back buffers and do swap buffers in the kernel, so I'm "only" concerned with the DRI lock here. The idea is that since we have the memory manager and the super-ioctl and the X server now can push cliprects into the kernel in one atomic operation, we would be able to get rid of the DRI lock. My overall question, here is, is that feasible? I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? Sorry for the question-blitz, and I'm sure some of those sound a bit naiive as I'm not too familiar with the lower levels of many drivers. But if we're planning to move away from the DRI lock in the near future, we need to figure what to do here. Or maybe we're not getting rid of the DRI lock anytime soon, but that would be a shame given that we've got everything else lined up. 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel