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:
- 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.
- 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@amd.com.
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