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

[Thomas Hellstr�m]

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. /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 __________________________________ 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel