From: Michel <mi...@da...> - 2002-06-03 23:06:59
|
On Mon, 2002-06-03 at 23:39, Linus Torvalds wrote: >=20 >=20 > On Fri, 31 May 2002, Keith Whitwell wrote: > > > > Also note that it actually asks for the pixcache to be flushed *twice* = - once > > by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT vi= a the > > ring) and once in radeon_do_pixcache_flush() which writes the register = via MMIO. >=20 > Btw, why _do_ we flush these things anyway? >=20 > I realize that we need to flush the engine in between switching from a DR= I > application and the X server itself, but that should be part of the lock > transfer, should it not? Right now the X server seems to (quite > unnecessarily) call in to radeon_cp_idle() all the time, even if no direc= t > rendering is happening at the same time. I think that's XAA syncing for direct framebuffer access. I don't see any direct RADEONCPWaitForIdle() calls in the driver anyway. I also think that the places where info->accel->NeedToSync is set are justified, they're to tell XAA it needs to sync before direct framebuffer access. Now I wonder if the various RADEON_WAIT_UNTIL_IDLE() and similar calls are actually necessary, especially in RADEONLeaveServer(). This way the chip goes idle before processing commands from a DRI client, which doesn't look terribly effective to me and shouldn't be necessary with the CP ring? > Am I missing something? Would it not be better to handle this in the DRM > locking code, and only flush when the lock is taken by somebody new? That > way, if there isn't any lock contention, there also won't be any > unnecessary flushes.. >=20 > (By "in the locking code", I don't actually mean the kernel itself: just > make the kernel return a different return code for "successfully got the > lock, previous owner was yourself" than for "successfully got the lock, > you were the last user", and then the X server and the DRI layer can avoi= d > doing things like RADEONEngineRestore() if we're the same user). Doesn't sound bad. :) Except that I suspect a lot of the flushes are really inevitable for the above reasons. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |