On Wed, Apr 26, 2017 at 03:36:19PM +0100, Tvrtko Ursulin wrote: > > On 26/04/2017 13:23, Chris Wilson wrote: > >Too early, it's the timeline (and syncs along it) that's interesting. > >For our contexts, we can hook into context-close, but we still have some > >foreign dma-fence-contexts to worry about. I was thinking of walking all > >timelines from the idle_worker. And possibly forcibly prune across > >suspend. > > Hm I don't see why it is too early. If request is getting freed, > there is no one waiting on it any longer, so how can it be OK to > keep that seqno in the map? The fence->seqno represents a known synchronisation point from our timeline to the fence->timeline. In the future, we know that we can skip all synchronisations onto that timeline that are older than the fence->seqno because we already have synchronised. That coupling persists after the fence itself is destroyed. It is why tracking it between timelines is more effective than just squashing repeats within a request. (This is perhaps more significant when we expend ring space to emit GPU commands for each sync point, i.e. hw semaphores.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
