Am 24.06.2016 um 15:17 schrieb Gustavo Padovan:
Hi Christian,
2016-06-24 Christian König <christian.koe...@amd.com>:
Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Hi all,
This is an attempt to improve fence support on Sync File. The basic idea
is to have only sync_file->fence and store all fences there, either as
normal fences or fence_arrays. That way we can remove some potential
duplication when using fence_array with sync_file: the duplication of the array
of fences and the duplication of fence_add_callback() for all fences.
Now when creating a new sync_file during the merge process sync_file_set_fence()
will set sync_file->fence based on the number of fences for that sync_file. If
there is more than one fence a fence_array is created. One important advantage
approach is that we only add one fence callback now, no matter how many fences
there are in a sync_file - the individual callbacks are added by fence_array.
Two fence ops had to be created to help abstract the difference between handling
fences and fences_arrays: .teardown() and .get_fences(). The former run needed
on fence_array, and the latter just return a copy of all fences in the fence.
I'm not so sure about adding those two, speacially .get_fences(). What do you
think?
Clearly not a good idea to add this a fence ops, cause those are specialized
functions for only a certain fence implementation (the fence_array).
Are you refering only to .get_fences()?
That comment was only for the get_fences() operation, but the teardown()
callback looks very suspicious to me as well.
Can you explain once more why that should be necessary?
Regards,
Christian.
What you should do is try to cast the fence in your sync file using
to_fence_array() and then you can access the fences in the array.
Yes, that seems a better idea I think. The initial idea was to abstract
the difference as much as possible, but it doesn't seem really worth
for .get_fences().
Gustavo
_______________________________________________
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
