On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
>
> 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?
How do you plan to ensure that X didn't change the cliprects after you
emitted them to the DRM ?
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
I seem to recall Eric Anholt did optimize the emission of radeon state atoms
a long time ago, and he got some speed improvements. You'd have to ask him
how much though. This could give us a rough idea of the performance impact
of emitting full state vs needed state, although this doesn't measure the
gain of removing lock contention. I might be totally wrong on this, this
dates back to a couple of years ago.
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?
Yes it probably has to go to the kernel anyway.
Stephane
-------------------------------------------------------------------------
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
