[PATCH 22/22] drm/amdgpu: fix reservation obj shared count bug

[Chris Wilson]

Quoting Christian König (2018-02-26 10:44:40)
> > We must call reserve_shared before amdgpu_bo_fence....
> Actually that's not correct. See reservation_object_add_shared_fence() 
> should replace the fence when it has the same context as a previously 
> added fence.
> 
> So we call reserve_shared only once and then call 
> reservation_object_add_shared_fence() multiple times, always with the 
> same context.
> 
> Writing this, Chris actually had patches which may have broken that 
> assumption, but as far as I know those aren't merged yet.

We haven't made progress on those (sorry, they are on the back burner).

Calling reserve_shared() once followed by multiple calls to
add_shared_fence() for the same context wouldn't break per se, just as
you noted has a chance to store the same context twice in the array.
So if you relied on the behaviour that you see the context only once in
the array later, yeah that broke. (My expectation is serving the context
twice would be a no-op, and it should boil down to should we pay the
cost of scanning for every add_shared_fence, or should that cost only be
paid later on by handling a no op. Imo, it's the second option that is
rarer but I have a pretty heavy bias from looking more often at the
will-it-scale tests.)
-Chris