On Mon, 2004-08-23 at 22:58, Thomas Hellström wrote: > Hi! > > Mike Mestnik wrote: > > --- Eric Anholt <[EMAIL PROTECTED]> wrote: > > > > > > > On Mon, 2004-08-23 at 15:24, Ian Romanick wrote: > > > > > > > Thomas Hellström wrote: > > > > > > > > > > > > > As some of you might have read on another thread, there is a > > > > > > > > discussion > > > > > > > > how to handle the X server (and possibly other) 2d contexts in the > > > > > > > > via / > > > > > > > > unichrome family of drivers that expects certain 2d engine register > > > > > values to stay the same even when other contexts or DMA commands > > > > > > > > have > > > > > > > > played. > > > > > > > > > > Looking at the now obsolete gamma driver and ffb_context.c, some > > > > > register values are saved at context switches whereas in other > > > > > > > > drivers > > > > > > > > this does not seem to happen. > > > > > > > > > > What is the common practice? That all clients always reinitialize > > > > > > > > the > > > > > > > > engines every time they are used or that the drm saves the registers > > > > > > > > > > that are commonly used by different clients as part of the context > > > > > > > > switch? > > > > > > > The common practice is to define a set of register "groups", and > > > > > > > define > > > > > > > a bit mask for with 1 bit per group (usually called "dirty bits"). > > > > > > > When > > > > > > > a context gets the hardware lock, it checks to see if any other > > > > > > > context > > > > > > > has held the lock since the last time it held it. If another context > > > > has, it looks at the bit mask (stored in the SAREA). Any set dirty > > > > > > > bits > > > > > > > mean the some other context modified some register in that group. The > > > > > > > > dirty register(s) is then reset to the value expect by the context now > > > > > > > > holding the lock. > > > > > > > Another way is what the radeon/r200 drivers do: When you grab the lock > > > from someone else, *all* state is dirty. You can see an example in > > > radeon_dri.c. When we grab the lock, we mark the 3d state invalid so > > > that the next use of it (Render acceleration) resets it all. > > > > > > To be totally correct, in my opinion, the EnterServer for Radeon should > > > be resetting some of the 2d state that it depends on, as well. As it > > > is, it looks like if someone wanted to set things like the default > > > offset in the 3d driver, they'd have to update the 2d driver to reset it > > > when grabbing the lock, bump the DDX version, and check for that version > > > in the 3d driver and deal with it appropriately. > > > > > > > > Are there alot of registers, more then 300? If not why would they be > > broken up into groups, I'm guessing each function/group only has 7 to 10 > > registers. It seams like you would wast more cycles on conditional jumps > > then on just pushing the state. > > > > > Thanks all. The register number is quite small; As long as we are > limited to the 2d engine, the choice is probably to let all clients > assume that register state is lost between HW_LOCKS. The other option > seems to be to let drm save the 2d engine and reload it when it is > "dirty" as part of the context switch.
It's even less expensive than that. In your 3d driver, you know that state has been lost when the full <driver>GetLock is called after the fast lock re-grab in the LOCK_HARDWARE macro from <driver>_lock.h fails (assuming via is like most of the other drivers). In the server, you know it's happened when the EnterServer is called from SwapContext, as seen in radeon_dri.c. This means that you only take the hit when you've actually lost state. To me, it seems like a pretty good tradeoff between simplicity (avoids another interface to be maintained between DDX/DRI) and performance. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
