From: Leif D. <lde...@re...> - 2003-02-22 22:04:36
|
On 22 Feb 2003, Michel D=E4nzer wrote: > On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: > > On 22 Feb 2003, Michel D=E4nzer wrote: > >=20 > > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote:=20 > > >=20 > > > I do wonder if the register writes in RADEONSetCursorPosition() cou= ld > > > interfere with the CP to cause FIFO overflows. Does anyone have an = idea > > > how to determine whether writes to certain registers go through the > > > FIFO? I asked ATI devrel about this but didn't get a reply. :( The = only > > > indication that these might not is that I'd expect it to cause prob= lems > > > much more frequently if they did. > >=20 > > IIRC, at least on mach64, hardware cursor position updates don't go > > through the draw engine FIFO=20 >=20 > Good, that makes a lot of sense of course. >=20 > > (any registers below dword offset 0x040 don't use the FIFO),=20 >=20 > Where did you find this information? Have you found anything similar > about Radeons anywhere? It's in the register reference and programmer's guide. I don't have docs= =20 on Radeons, so I don't know if there is a similar convention there. =20 > > so locking isn't necessary. However, we do lock the DRM when updatin= g=20 > > the cursor image, since it blits the image to the framebuffer through= =20 > > the host data FIFO.=20 >=20 > The radeon driver writes it to the framebuffer directly. Actually, looking at it again, so does mach64 (I was thinking of an XAA function). However, the DDX does an XAA sync before writing the cursor image to synchronize the framebuffer access. Since we do the 3D/2D sync in the XAA sync, I had to put a DRILock/Unlock around it. --=20 Leif Delgass=20 http://www.retinalburn.net |