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
