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. [Chris Wilson] (We now call it "the kernel context", and compare against the device-wide pointer). _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx