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

[Daniel Vetter]

Hi Chris,

Am Do, 30.12.2010, 12:13, schrieb Chris Wilson:
> 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.

An idea that just crossed my mind (probably bollocks, but who knows):
The number of buffers a context references is usually bounded (a few
indirect state bos + a bo per texture unit + render targets), so why not
specify how many persistent bos a given context uses. In execbuffer we add
a new reloc field (there are enough bits free in the domain fields) that
indicates which (if any) context bo slot this buffer should be in.
The kernel then puts that bo with a reference into the specified slot
(of the array allocated at context creation time), freeing any previous
bo in the same slot. Right before using the context (mi_batchbuffer or
mi_set_context) we can then walk this array and check whether all required
bos are still at the right place (by remembering their gtt_offset at reloc
time).

This way userspace doesn't have to track a list of context bos and the
kernel gem stays in full control. And specifying the context relation of
a bo toghether with the relocation that actually uses it is probably the
clearest solution.

And wrt restoring the gtt offset: I think to guarantee this, we need
ppGTT. In the GGTT we might get unlucky and a scanout buffer sits at
the desired spot. So at least for bring-up (until ppGTT works) we need
to be able to bail out in the kernel and politely ask userspace to fix up
the mess ;)

Cheers, Daniel