From: Leif D. <lde...@re...> - 2002-06-15 17:25:43
|
On Sat, 15 Jun 2002, Keith Whitwell wrote: > Linus Torvalds wrote: > >=20 > > On Fri, 14 Jun 2002, Jos=E9 Fonseca wrote: > >=20 > >>So to avoid being constantly checking for conclusion before asking to > >>process new entries we devised a different scheme: > >> > >> - after adding new entries to the ring > >> > >> - toggle the end flag of the previous last entry, so that the engin= e > >>will also process our just commited buffers > >> > >=20 > > If this is in non-coherent memory (AGP), I hope you do an "sfence" in > > between those two stages? You also need to make sure that the compil= er > > hasn't re-ordered them (ie a compiler barrier() in between), regardle= ss of > > memory ordering. > >=20 > > I also hope you do the toggle with a locked cycle so that you don't l= ose > > any information.. >=20 > Is this necessary if the toggle is really just a write? Jose, you're n= ot=20 > doing a read-modify-write operation on that flag are you? Actually, with the current implementation it is a read-modify-write. =20 Jose, we could avoid that by caching the ring offset and data for=20 BM_COMMAND from the (previous) tail as my original patch did. =20 > I suppose to some extent we're relying on the atomicity of the mach64's= use of=20 > that flag as well -- I don't know if there are any obvious ways they co= uld get=20 > it wrong (I assume they just fetch it once...) -- so that's probably no= t a=20 > huge problem. >=20 > Keith >=20 >=20 >=20 >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?s= ource=FFdntextlink >=20 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel >=20 --=20 Leif Delgass=20 http://www.retinalburn.net |