Jerome Glisse wrote: > 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 ? > So what happens is that the drm fence handler calls needed_flush() when it has signaled a fence_type on a fence. If needed_flush() determines that further flushing is needed, it should then check if there is a flush in the command stream that would perform the required action, and if so return zero. A simple way to track flushes is to store the sequence number for the last flush. If that sequence number is higher than the current sequence number, no flush is needed, and needed_flush() would return zero.
So yes, you need to check fc->pending_flush during poll, and make sure needed_flush() is smart enough to check the ring for previous flushes that would do the job, so we don't issue any unnecessary flushes. So over to the question, how does the poll() function tell that a flush has executed? One option is to have a separate list with all flushes in the ring, and a corresponding sequence number. Everytime we hit a new sequence number we check the list, and see if a flush has executed, and in that case call drm_fence_handler() with the correct fence_type. One other option is to use fence->native_type. When TYPE_EXE signals on a fence with a non-zero native_type, it will also automatically signal fence->native_type on itself and all previous fences. There is a problem with this, however, and that is that such a fence might disappear when it's no longer referenced by a buffer and thus we will lose track of that flush. This can probably be fixed with refcounting tricks, but now it starts to get more and more complicated. If you look in the intel_driver, native_type is used exactly in this way to track flushes that are programmed by user-space. Here, a driver-specific fence-flag is used to tell the intel fence driver that we have programmed an MI_FLUSH. However, if you look even more closely, the intel needed_flush() implementation ignores these user-space flushes, unless they occur on the current fence. This is to avoid the previously mentioned ring round-trip delay. So currently it's a bit stupid since even if a flush occurs on the next fence, it will go on initiating a sync_flush operation. /Thomas /Thomas ------------------------------------------------------------------------- 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
