On Tue, Jan 19, 2016 at 07:02:52PM +0000, Dave Gordon wrote: > During startup, the driver creates a unique "intel_context" that will > provide a home for orphan requests (i.e. those generated by the driver > internally, not associated with user batchbuffers). > > However, one of the infelicities of the current code is that the driver > keeps a per-engine pointer to the default context for that engine (this > is probably from a decision made early in execlists implementation, > when it was thought that a context was engine-specific, and not revised > when it was decided that an "intel_context" represents a multiplex of > engine-level contexts). All these per-engine pointers actually end up > pointing to the same unique object. > > To compound this, the refcounting is bogus; the driver holds just one > reference to the default context, even though there are multiple pointers > to it (RCS is considered to hold this "on behalf of" the other engines, > but this can lead to problems during unload as it makes the code sensitive > to the order of engine teardown -- RCS should be done last, but it isn't). > > Also, some of the execlists batch submission code treats the default > context differently from any other; testing for it by comparing against > the per-engine pointer is quite clumsy, especially in debugfs where > contexts are enumerated from a global list and therefore not automatically > known to be associated with a particular engine. > > Therefore, we should replace the per-engine pointers with a single > driver-wide reference, which will make the refcounting sane and simplify > the code that uses this context for non-user-related requests. > > THIS patchset does NOT address the execlists code's special handling of > the default context, but it will simplify the planned future cleanup of > that code. > > v3: don't flag the context created during startup (and fully instantiated > on all engines) for driver-internal purposes as "is_global_default", > 1448630935-27377-1-git-send-email-chris@xxxxxxxxxxxxxxxxxx notwithstanding. > (We now call it "the kernel context", and compare against the device-wide > pointer). [Chris Wilson] > > v4: Rebased entire series vacuumed up, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx