On Thu, May 19, 2016 at 09:46:47AM +0200, Christian König wrote:
> Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> >On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
> >>+static void collection_check_cb_func(struct fence *fence, struct fence_cb *cb)
> >>+{
> >>+ struct fence_collection_cb *f_cb;
> >>+ struct fence_collection *collection;
> >>+
> >>+ f_cb = container_of(cb, struct fence_collection_cb, cb);
> >>+ collection = f_cb->collection;
> >>+
> >>+ if (atomic_dec_and_test(&collection->num_pending_fences))
> >>+ fence_signal(&collection->base);
> >>+}
> >>+
> >>+static bool fence_collection_enable_signaling(struct fence *fence)
> >>+{
> >>+ struct fence_collection *collection = to_fence_collection(fence);
> >>+ int i;
> >>+
> >>+ for (i = 0 ; i < collection->num_fences ; i++) {
> >>+ if (fence_add_callback(collection->fences[i].fence,
> >>+ &collection->fences[i].cb,
> >>+ collection_check_cb_func)) {
> >>+ atomic_dec(&collection->num_pending_fences);
> >>+ }
> >>+ }
> >We don't always have a convenient means to preallocate an array of
> >fences to use. Keeping a list of fences in addition to the array would
> >be easier to user in many circumstances.
>
> I agree that there is use for such an implementation as well, but as
> mentioned in the last review cycle we intentionally chose an array instead
> of a more complex implementation here.
>
> This way the array can be passed to function like fence_wait_any_timeout()
> as well.
+1 on fence_array.
> I also suggested to rename it to fence_array to make that difference clear
> and allow for another implementation to live side by side with this.
>
> My crux at the moment is that I need both for the amdgpu driver, an array
> based implementation and a collection like one.
>
> Gustavo would you mind if I take your patches and work a bit on this?
I think the goal is to start landing the atomic fence stuff in 4.8.
Probably simplest if we converge on a first iteration that I can pull into
drm-misc right after 4.7-rc1. Then you can both base your respective work
on top of that branch (it's a stable one, so can even base official
branches on it).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
