> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > > For flexible GEM context creation, we factor out __i915_gem_create_context > as the core logic of creation a GEM context. After the refactor, it more > likesa context creation servcie, which is able to create context by > explicit requirement of upper level components, not by the assumptions of > incoming parameters. > > For the assumptions in original implementation, we keep them in the upper > level wrapper: i915_gem_create_context(). IMO combining 5/6/7 is clearer to give a full picture how create_context is refactored, but will leave to i915 guys to comment the preferred style. > > alloc_context_idr() is another function factored out to setup a IDR for > ordinary GEM context. Some context, e.g. GVT context, maybe more than one > kernel context in furture (currently there is only one kernel context: the > default context) doesn't need a IDR. So we make it an option in context > creation. > Could you elaborate why IDR cannot be used for GVT context. Even if it is not used, keeping it can reduce the code divergence as long as no function is impacted... Thanks Kevin _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
