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
how to handle the X server (and possibly other) 2d contexts in the
unichrome family of drivers that expects certain 2d engine register
values to stay the same even when other contexts or DMA commands
Looking at the now obsolete gamma driver and ffb_context.c, some
register values are saved at context switches whereas in other
this does not seem to happen.
What is the common practice? That all clients always reinitialize
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
The common practice is to define a set of register "groups", and
a bit mask for with 1 bit per group (usually called "dirty bits").
a context gets the hardware lock, it checks to see if any other
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
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.