Jerome Glisse wrote: > On Fri, 29 Feb 2008 09:46:48 +0100 > Thomas Hellström <[EMAIL PROTECTED]> wrote: > > >> Thanks. >> Added Jerome's flush-bit-in-sequence-blit suggestion and a section about >> the command_stream_barrier() callback, which might be handy also for >> Radeons. >> >> /Thomas >> >> > > Thomas i got one last question to finish cleaning up my fence code :) > The wait callback is there to wait for a fence and mask argument is > the type we are waiting for this fence ? I don't understand why we > need the mask argument while the fence already have its type defined ? > Is this for the following case: > > Userspace submit cmd with a fence toto of type FENCE_TYPE_EXE > Userspace say well now i want to wait for toto fence but with > type RW flush and not only FENCE_TYPE_EXE. > > Nope, userspace isn't allowed to do that. It's because an object is idle if ((object->fence_type & object->fence->fence_type) == object->fence_type) where object->fence-type is always a subset of fence->fence_type.
Typically a fence almost always has DRM_BO_FENCE_TYPE_EXE | DRM_BO_FENCE_TYPE_RW, Now, batch buffers have bo->fence_type = DRM_BO_FENCE_TYPE_EXE. So to idle batch buffers, it's sufficient wo wait for DRM_BO_FENCE_TYPE_EXE. We don't need to wait for the fence to expire completely. /Thomas > 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
