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

[Daniel Vetter]

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.

> 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.

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 ...

> 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).

> Thanks.
> Ben

Cheers, Daniel