Re: [RFC] drm/i915: Extend CREATE_CONTEXT to allow inheritance ala clone()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Michał Winiarski (2017-12-19 12:15:39)
> On Fri, Dec 15, 2017 at 01:20:17PM +0000, Chris Wilson wrote:
> > A context encompasses the driver's view of process related state, and
> > encapsulates the logical GPU state where available. Each context is
> > currently equivalent to a process in CPU terms. Like with processes,
> > sometimes the user wants a lighter encapsulation that shares some state
> > with the parent process, for example two threads have unique register
> > state but share the virtual memory mappings. We can support exactly the
> > same principle using contexts where we may share the GTT but keep the
> > logical GPU state distinct. This allows quicker switching between those
> > contexts, and for userspace to allocate a single offset in the GTT and
> > use it across multiple contexts. Like with clone(), in the future we may
> > wish to allow userspace to select more features to copy across from the
> > parent, but for now we only allow sharing of the GTT.
> 
> Our timelines are still per-vm and not per-ctx.
> This means that schedule() will have slightly unexpected behavior when dealing
> with two context of different priority sharing a VM.

Ugh. Thanks for the reminder, the intent here is indeed to have separate
timelines. We still do have an ordering requirement within the vm, but
the shared vma should just complicate future locking. Hmm, off the top
of my head, that's the only implicit timeline we have to be concious
off. Now to remind myself if it can just be its own ordered list
disjoint from the exposed timeline.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux