Am 30.01.2018 um 13:50 schrieb Chris Wilson:
Quoting Christian König (2018-01-30 12:26:05)
Am 30.01.2018 um 10:32 schrieb Chris Wilson:
Adding a shared fence to a reservation_object is currently split into
two handlers, one to insert the fence into the existing array and the
other to replace the existing array with a new larger array. The first
step in both of these routines involves scanning the existing array to
decide if it can prune any of the existing fences.
As both routines perform essentially the same loop, we can combine them
into one routine. During the first scan over the existing array, we
search for a slot with which we can reuse for the new fence (discarding
the previous). If we find no available slot to reuse, and the array is
already at its max size, then we know that we need to switch to the
larger array, and that no existing fence needs to be discard, they can
all be copied over.
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-627 (-627)
Function old new delta
__warned 2352 2350 -2
reservation_object_reserve_shared 196 185 -11
reservation_object_add_shared_fence 1272 658 -614
Looks good to me, but still two comments:
1. It looks like we now can have the same context multiple times in an
reservation object. Could we avoid that?
Not without scanning the entire array. Multiple fences from the same
context isn't an issue for either of us as we both reduce down to the
last fence on each context, and in the case of iteratively waiting on
each fence in the reservation_object it is not noticeable.
The trade-off is in choosing to scan the entire array.
So the only extra overhead is when scanning the fences during command
submission and there it doesn't really matter if we need to handle an
already signaled one or multiple signaled one from the same context.
Well, that is a good point.
2. When the we copied the fences over into the new container we
previously removed all signaled one. That had the really nice side
effect of handling them during command submission quite a bit faster.
Can we keep that as well?
We prove that before we copy to a new array, there are no currently
signaled fences left.
Ah, yeah missed that. Ok in this case the patch is Reviewed-by:
Christian König <christian.koenig@xxxxxxx>.
Regards,
Christian.
Ime, when processing the fences you generally have to discard the signaled
fences anyway, so the benefit for add_shared_fence is in pruning any
signaled fences to prevent realloc; and I prefer the more gradual
approach for the trade-off in reducing the work on adding the fence.
The alternative is that we basically run the replace algorithm and
decide to the final op inplace (and not consume obj->staged) if we only
need to replace/add one fence.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
