Hi!

Mike Mestnik wrote:
--- Eric Anholt <eta@lclark.edu> 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.

/Thomas


  
-- 
Eric Anholt                                eta@lclark.edu          
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-devel@lists.sourceforge.net
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 


-------------------------------------------------------
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel