The r200 driver (and IIRC to a lesser degree radeon too) used to have tcl
problems which often resulted in heavy flickering. This was solved somewhat a
long time ago by submitting the state atoms in a "proven by trial-and-error"
fixed ordering, though noone really knew why this would be necessary (nor
obviously what the order of the atoms should be). More recent investigations
however showed that fglrx does emit writes to 0x2284 before it writes to the
R200_SE_VAP_CNTL reg (and in turn it seems to emit the R200_SE_VAP_CNTL reg
quite often too), and (sometimes) before emitting tcl vector state. In fact, the
r300 driver indeed does that too. So I tried writing to that reg before any
access to the tcl vector state (same as what r300 driver does). This indeed
fixed all flickering problems even with an old user-space driver which didn't
have a fixed ordering of the state atoms (Mesa 5.0.2).
I'd be happy to really fix that, but even after some discussion on irc I
couldn't figure out WHEN this register in fact needs to be emitted. Emitting it
every time vector tcl space is accessed might be both overkill (accessed quite
frequently, could potentially hurt performance) and insufficient (what about tcl
scalar state, other vap regs). Currently without that patch there still are some
slight flickering problems sometimes (I can see them with a rv250 and nwn when
hyperz is active). I'm not sure the drm is the right place to do this (simpler
to patch, but maybe the drm can't really know when to emit it).
btw if you're wondering this doesn't seem to fix the lockups/crashes which seem
to be related to tcl - I've seen some of those drmRadeonIrqWait: -16 recently
too both with and without that patch, though only once every few hours of heavy use.
So I'd be happy if someone had some insight on when that reg should really be
emitted.