[Intel-gfx] [PATCH 02/25 v2] drm/i915: preliminary context support

[Ben Widawsky]

On Tue, 5 Jun 2012 15:23:26 +0300
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Mon, Jun 04, 2012 at 02:42:42PM -0700, Ben Widawsky wrote:
> > Very basic code for context setup/destruction in the driver.
> > 
> > Adds the file i915_gem_context.c This file implements HW context
> > support. On gen5+ a HW context consists of an opaque GPU object which is
> > referenced at times of context saves and restores.  With RC6 enabled,
> > the context is also referenced as the GPU enters and exists from RC6
> > (GPU has it's own internal power context, except on gen5).  Though
> > something like a context does exist for the media ring, the code only
> > supports contexts for the render ring.
> > 
> > In software, there is a distinction between contexts created by the
> > user, and the default HW context. The default HW context is used by GPU
> > clients that do not request setup of their own hardware context. The
> > default context's state is never restored to help prevent programming
> > errors. This would happen if a client ran and piggy-backed off another
> > clients GPU state.  The default context only exists to give the GPU some
> > offset to load as the current to invoke a save of the context we
> > actually care about. In fact, the code could likely be constructed,
> > albeit in a more complicated fashion, to never use the default context,
> > though that limits the driver's ability to swap out, and/or destroy
> > other contexts.
> 
> I'm not actually familiar with the GPU state management in the driver
> yet, but I assume that currently much of the state has to be uploaded
> every time a client submits rendering commands to the GPU.

That's correct.

> 
> So would it make sense to have an implicit context created for each
> client? That way each client could just pretend that it's the only user
> of the GPU and wouldn't have to worry about someone else corrupting the
> GPU state.
> 

An earlier implementation of context support had such an idea. And even
Daniel brought it up again recently. It's certainly not a bad idea. The
only reason to do it is what you mention, regarding corruption
prevention. The real way to do that though requires proper PPGTT
support. Until we have that, I think this point isn't so important.

Old userspace isn't ever going to stop emitting all of it's state, and
new clients will still have to be able to fall back to using older
kernels. As such, the idea of being able to remove the "emit everything"
from userspace won't likely go away any time soon.

Another reason not to do it is while context objects are small now, they
do increase in size in coming generations. If we begin creating a lot of
contexts, we potentially need a lot more GTT to handle them.

I think we should discuss this again when real PPGTT support is in
place.


-- 
Ben Widawsky, Intel Open Source Technology Center