> 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. >
Thanks. I'll have a look. The thing is that it might be very cheap both cpu-wise and implementation-wise to let XAA set up the needed registers in the 2D engine every time it uses it. And it might be needed anyway so that the 2D engine can be used elsewhere in the X server, mainly for blitting video data. In that case no DRM modifications are needed, as both 3D (?) and XvMC dri clients assume that the 2D engine is uninitialized when they take the HW lock. In fact there is already a "saved minimal 2d engine state" struct in the unichrome DDX that is used in case an XvMC dri client dies without restoring the registers. However, It might be good for avoiding pitfalls in the future, for future extensions and maybe also for possible directfb use of DRM to have a proper 2D engine context switch. Regards Thomas > -- > 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 > ------------------------------------------------------- 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
