On Jan 12, 2017 8:04 AM, "Chris Wilson" <chris@xxxxxxxxxxxxxxxxxx> wrote:
On Thu, Jan 12, 2017 at 05:48:49PM +0200, Mika Kuoppala wrote:Hmm. right. Basically we have to ignore all objects if svm. Basically we
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
>
> > On Mon, Jan 09, 2017 at 06:52:53PM +0200, Mika Kuoppala wrote:
> >> +static int i915_gem_context_enable_svm(struct i915_gem_context *ctx)
> >> +{
> >> + int ret;
> >> +
> >> + if (!HAS_SVM(ctx->i915))
> >> + return -ENODEV;
> >
> > How does legacy execbuf work with an svm context? It will write the
> > ppgtt, but those are no longer read by the GPU. So it will generate
> > faults at random addresses. Am I right in thinking we need to EINVAL if
> > using execbuf + context_is_svm?
>
> Yes without further experiments, it is best to block the legacy path
> with -EINVAL. I will add this.
>
> I guess with some tweaking the legacy interface could be made to work,
> but it would need is_svm_context() checks in rather many places
> in the execbuffer path to avoid relocations/pins.
strip off everything (having to EINVAL if passed in relocs etc) and more
or less call exec_svm. The advantage is that it keeps the request tracking
of the objects correct, but it can only work with softpinning of the
objects at their cpu addresses. (I don't propose we map the object in
the cpu table at the ppgtt offset!)
Anyway the decision has to be made upfront whether we want to support
the frankenapi.
FWIW I think the Beignet team wanted this functionality to make their implementation easier. It's a bit more invasive but might be worth it for userspace to make their transition easier.
Jesse
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
