Re: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Bloomfield, Jon (2019-08-07 15:33:51)
[skip to end]
> We didn't explore the idea of terminating orphaned contexts though (where none of their resources are referenced by any other contexts). Is there a reason why this is not feasible? In the case of compute (certainly HPC) workloads, there would be no compositor taking the output so this might be a solution.

Sounds easier said than done. We have to go through each request and
determine it if has an external reference (or if the object holding the
reference has an external reference) to see if the output would be
visible to a third party. Sounds like a conservative GC :| 
(Coming to that conclusion suggests that we should structure the request
tracking to make reparenting easier.)

We could take a pid-1 approach and move all the orphan timelines over to
a new parent purely responsible for them. That honestly doesn't seem to
achieve anything. (We are still stuck with tasks on the GPU and no way
to kill them.)

In comparison, persistence is a rarely used "feature" and cleaning up on
context close fits in nicely with the process model. It just works as
most users/clients would expect. (Although running in non-persistent
by default hasn't show anything to explode on the desktop, it's too easy
to construct scenarios where persistence turns out to be an advantage,
particularly with chains of clients (the compositor model).) Between the
two modes, we should have most bases covered, it's hard to argue for a
third way (that is until someone has a usecase!)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx