[Intel-gfx] [RFC] drm/i915: context support unit test

[Chris Wilson]

On Thu, 30 Dec 2010 11:07:19 +0100 (CET), "Daniel Vetter" <daniel at ffwll.ch> wrote:
> Hi Ben,
> 
> Am Mi, 29.12.2010, 05:03, schrieb Ben Widawsky:
> > There is no tie in to multiple ringbuffer support. A client may allocate
> > a context for all ringuffers, or one for each ringbuffer. I too must
> > figure out if this is relevant to anything but the graphics engine.
> 
> I've been simply thinking that using a hw context on multiple rings is
> probably a bad idea. Hence is should be impossible to do. Maybe it's
> indeed possible and makes sense/is actually required to accomplish
> your goals? If not, I think your api needs some clarification for this.

Per usual, Daniel is right on the mark. So let's see if I can add anything
useful...

> > The immediate plan is to allocate space for the HW context at the time
> > the client gets (lazily or not) a new context. The memory will be pinned
> > at this point, because it's somewhat difficult to make sure the memory
> > will be there on future context switches. This is a possible area for
> > improvement, but to do this would require keeping tracking of the last
> > context to run, and then possibly paging in memory of that context
> > before the new context can run.
> >
> > Unfortunately I'm new to this HW and SW design, so I may not have
> > totally followed your questions about eviction, or invalidation. The
> > answer is, I don't yet know. If your assumption is right, and it's
> > possible to set the hardware state such that it may reference memory in
> > a subsequent batch that's not referenced in the subsequent batch
> > buffers, then there is some work to be done which isn't part of the
> > initial implementation. It will be up to user space to pin any objects
> > which may be referenced in the future. After the initial implementation,
> > we can decide how to proceed, but your suggestion seems reasonable to
> > me, and I'd have to do more research.
> 
> The scenario I have in mind:
> 0. You create 2 hw contexts.
> 1. You run a batchbuffer with context 1.
> 2. You run a batchbuffer with another context. This may evict a few indirect
>    state bos (and other stuff) used by context 1.
> 3. You reuse context 1 in the next batchbuffer, hw reads garbaged when
>    loading the indirect state. I don't know whether hw actually does this
>    but similar problems exist for textures, render targets, ...
> 
> You mention that userspace must pin any objects that may be referenced
> in the future. I absolutely don't like this plan. With kms gem has full
> control over the memory layout. In theory we could even move around
> scanout buffers if we exchange the backing store and execute a flip.
> Forcing userspace to pin buffers (rather large ones in case of textures/
> render targets) is completely against the spirit of gem. The simplest
> way out is to invalidate a context a soon as a bo gets moved out of the
> gtt (if it has ever been associated with that context) and tell userspace
> that it needs to reissue the batch with a full context-reinit sequence.

Exactly. Relying on userspace to pin the layout in the GTT here is just
fail. Active contexts must be tied into the batchbuffer+eviction system
and be managed accordingly. 
 
> Of course, whether that's the right thing to do depends upon the anticipated
> use-case of hw contexts. Can you elaborate a bit on this? As an outside
> contributor I'm slightly out of the loop in such matters ...

This is just the first step towards run-lists and ppGTT. We've always
postulated that there might be some minor gain from maintaining context
between batchbuffers, but that is a secondary goal in comparison to the
incremental change towards the new dispatch mechanisms in Cantiga+,
particularly SandyBridge+.
 
> > Regarding lazy creation:
> > The current design allows a client to create multiple contexts, or even
> > possibly share contexts. I'm not sure of an easy way to meet those goals
> > with a lazy allocation. My original plan was to modify the gem alloc API
> > so that each bo would be associated with a context, but either way it
> > involved adding a new API (since I couldn't destroy the old alloc API),
> > and I figured there may be some uses for contexts which don't require a
> > bo in the future.
> 
> I don't think there's any valid use-case for userspace to access the
> contents of a hw context (as using bos would allow). Hence I think handling
> hw contexts separately from buffer objects is a good thing. Sharing them
> is probably of little value (safe for some not yet publicly disclosed
> upcoming hw feature).

The contents of a HW context are not really privy to the driver, though
they are detailed on a per-chipset basis in the specs and one could
theoretically manipulate those contexts from userpsace. Without a valid
use case, we should restrict those to a per-file handle. Creating a global
namespace for contexts and permitting sharing between processes could be
done in exactly the same manner as named buffers, except that again I
don't believe there is a usecase for that, not even for shared GLX
contexts and the userspace synchronisation would seem to make it
nonsensical anyway.

The real issue is that once a bo has been used with a context, how can we
notify the kernel that context no longer references that bo (without
invoking a CS parser). This would seem simplest with another ioctl to
associate and disassociate bo with contexts, that would be serialised with
the execbuffer (pipelined of course!) in the same manner as tiling
changes. The active context + bo could still be evicted on mass, just so
long as we add a mechanism for restoring the gtt_offset for a particular
bo.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre