On Wed, 27 Feb 2008 17:08:41 +0100 Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Thomas Hellström wrote: > Some additional info on this: > flush() only needs to start a flush, and poll() will report it when it's > done, but note that on, for example intel, the flush mechanism currently > implemented doesn't have an IRQ that reports when it's done. Hence the > polling part of the intel fence wait. A better way of implementing this > is to have flushes go through a high-priority ring, accompanied by a > user irq. Not done yet. > A third way is to just add an MI_FLUSH to the ring and keep track of its > execution. The disadvantage of this is that the ring might be full of > rendering commands that will take a lot of time to complete and we will > drain the ring waiting for idle buffers. Well problem on radeon is that flush can take time ie we have to insert command in the ring to flush the whole pipeline from vertex to fragment. But i guess that i will need to have some real use case to see if it leads to drain the ring (i hope not :)) > Note also, that if poll() sees that fc->flush_pending is non-zero, it > should also start a flush and clear fc->flush_pending. It can be set to > non-zero in the drm fence handler. Do we really have to do this ? I mean if i get some one polling for a buffer i don't want to insert flush command into the ring each time i poll with fc->flush_pending being non zero, as last poll might already have inserted such command. Or do i have to keep track in the driver of current pending flush and have a mecanism to minize the number of flush i am sending ? Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
