Re: Proper way of implementing context switches....

[Mike M. <che...@ya...>]

--- Eric Anholt <et...@lc...> 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.

> -- 
> Eric Anholt                                et...@lc...          
> http://people.freebsd.org/~anholt/         anholt@FreeBSD.org
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail