On Thu, Dec 30, 2010 at 01:48:36PM +0100, Daniel Vetter wrote:
> 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.
I'll need to research this one more.
>
> 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 ;)
I agree with this. Depending on what the HW does when it loads state, it
might also require allowing the client to have a way to prevent
restoring context on the next submission. I think it would be good to
add this to the API even if HW doesn't require it.
Either way, I think this gets messy if we allow sharing contexts amongst
clients. I hope nobody has a good use case for sharing contexts :-).
>
> Cheers, Daniel
>
Ben
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
