[PATCH] Remove spurious use of MI_SET_CONTEXT.

[Kristian Høgsberg]

On Dec 3, 2007 4:20 PM, Keith Whitwell <keith at tungstengraphics.com> wrote:
...
> >> Just emit MI_SET_CONTEXT in place of the current batchbuffer preamble.
> >> Nothing can interrupt a batchbuffer half-way through in our system.
> >
> > MI_SET_CONTEXT has to go in a ring buffer, it can't go in a batch
> > buffer.
>
> I had trouble understanding this -- but indeed the address for the
> context is a *physical* address in system memory...  Fabulous.

No, it can be a GTT offset too, but it has to present when the context
is swapped out.  That is not under our control, because it happens
when the next context is swapped in.  So it has to be a no-evict
buffer.  We don't want to fragment the GTT with no-evict buffers for
this stuff, so the physical address option looks more interesting.

> That makes the whole scheme less interesting to me as it does rely on
> the kernel doing the state management, and at this point I don't really
> see this as being hugely worthwhile.

What did you have in mind?  The context buffers are opaque, it's just
a cookie you hold on to for the hardware. You can't peek into them and
manipulate the state anyway, so it doesn't seem to me that there's a
big difference in whether the kernel or user space track the state
buffers and issue the MI_SET_CONTEXT.

> Before you do this, it would be worthwhile to disable the preamble emit
> from the i915 driver and see if there is any measurable benefit.  As
> long as you only run a single context and disable EXA, nothing bad
> should happen.

I'll give that a try, and the thing to compare against is state
emission on every batch buffer, which is what we'll be doing without
the DRI lock.  No matter how it turns out, I doubt it will be a
performance regression, and will help with the EXA state tracking too.

Kristian