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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
