"Volkin, Bradley D" <bradley.d.volkin@xxxxxxxxx> writes: Hi Bradley, > [snip] > > On Thu, Sep 18, 2014 at 07:58:30AM -0700, Mika Kuoppala wrote: >> @@ -577,7 +596,7 @@ static int do_switch(struct intel_engine_cs *ring, >> vma->bind_vma(vma, to->legacy_hw_ctx.rcs_state->cache_level, GLOBAL_BIND); >> } >> >> - if (!to->legacy_hw_ctx.initialized || i915_gem_context_is_default(to)) >> + if (!to->initialized || i915_gem_context_is_default(to)) >> hw_flags |= MI_RESTORE_INHIBIT; >> >> ret = mi_set_context(ring, to, hw_flags); >> @@ -618,26 +637,19 @@ static int do_switch(struct intel_engine_cs *ring, >> /* obj is kept alive until the next request by its active ref */ >> i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state); >> i915_gem_context_unreference(from); >> - } >> >> - uninitialized = !to->legacy_hw_ctx.initialized && from == NULL; >> - to->legacy_hw_ctx.initialized = true; >> + /* We inherit the state from the previous context */ >> + to->initialized = true; >> + } > > Regarding these two hunks, I may have asked this question before but if > so I've forgotten the answer. Why do we want to set MI_RESTORE_INHIBIT > when switching to the default context? Why do we want to inherit state > from the previous context? > > I assumed that when switching to an initialized context we would always > want to restore its last state. > I would have been pondering the same questions. Perhaps it has something to do with the fact that default context should not assume anything about its previous state and thus userspace needs to initialize everything fully. And also to avoid the context switch performance hit on restoring. Ben might know answer. My plan is to experiment with making master copy of the first fully initialized state and use it as a read-only bo to initialize all subsequent contexts from. Atleast with the code, we could measure the perf impact. -Mika _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
