On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote: > 2016-08-03 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>: > > > On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > > > > > > Signalling doesn't need to be enabled at sync_file creation, it is only > > > required if userspace waiting the fence to signal through poll(). > > > > > > Thus we delay fence_add_callback() until poll is called. It only adds the > > > callback the first time poll() is called. This avoid re-adding the same > > > callback multiple times. > > > > > > v2: rebase and update to work with new fence support for sync_file > > > > > > v3: use atomic operation to set enabled and protect fence_add_callback() > > > > There's actually a spare bit in fence->flags you can use for this. > > > > #define POLL_ENABLED FENCE_FLAG_USER_BITS > > Wouldn't it be better to add a new bit to fence_flags_bit? sync_file is a user of struct fence, so it should claim one of the bits already reserved for users. Those reserved bits are meant only for the owner of the fence, if we did indeed need to share that bit with other consumers of the sync_file->fence_array then adding it to fence_flags_bits make sense. I don't see any reason at present why it should be anything other than a private bit to sync_file atm. Promoting it later (from private to shared) would also not be an issue. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
