From: Thomas H. <th...@tu...> - 2008-02-29 12:25:28
|
Jerome Glisse wrote: > On Fri, 29 Feb 2008 09:46:48 +0100 > Thomas Hellström <th...@tu...> 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 <gl...@fr...> > |