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
