On 25/03/2019 09:03, Chris Wilson wrote:
The headline change is the wholehearted decision to allow the user to establish an ctx->engines mapping of [rcs0, rcs0] to mean two logically distinct pipelines to the same engine. An example of this use case is in iris which constructs two GEM contexts in order to have two distinct logical ccontexts to create both a render pipeline and a compute pipeline within the same GL context. As it it the same GL context, it should be a singular timeline and benefits from a shared ppgtt; a natural way of constructing a GEM counterpart to this composite GL context is with an engine map of [rcs0, rcs0] and single timeline. One corollary to this is that given an ctx->engines[], we cannot assume that (engine_class, engine_instance) is enough to adequately identify a unique logical context. I propose that given user ctx->engines[], we force all subsequent user engine lookups to use indices. Thoughts?
I guess we need to hear from Mesa - is one GEM context a big win there, as opposed to two contexts with shared PPGTT? If single timeline is desired between the two it might be, but I don't know.
Having seen the amount of new patches I am naturally averse towards having to review them just to get back to Virtual Engine.
Is there a way to decouple the new feature request to after Media Scalability? It sounds that there should be - we could start with disallowing [rcs0, rcs0] and then allow it later.
Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
