Re: [PATCH] drm/i915: Use the new vm [un]bind functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 20, 2013 at 3:24 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> On Fri, Sep 20, 2013 at 12:43 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>> On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
>>> @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
>>>        * batch" bit. Hence we need to pin secure batches into the global gtt.
>>>        * hsw should have this fixed, but let's be paranoid and do it
>>>        * unconditionally for now. */
>>> -     if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
>>> -             i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
>>> +     if (flags & I915_DISPATCH_SECURE) {
>>> +             struct i915_address_space *ggtt = obj_to_ggtt(batch_obj);
>>> +             /* Assuming all privileged batches are in the global GTT means
>>> +              * we need to make sure we have a global gtt offset, as well as
>>> +              * the PTEs mapped. As mentioned above, we can forego this on
>>> +              * HSW, but don't.
>>> +              */
>>> +             ret = i915_gem_object_bind_to_vm(batch_obj, ggtt, 0, false,
>>> +                                              false);
>>> +             if (ret)
>>> +                     goto err;
>>
>> bind_to_vm() has unwanted side-effects here - notably always allocating
>> a node and corrupting lists.
>>
>> Just pin, ggtt->bind_vma, unpin. Hmmm, except that we also need a
>> move_to_active (as we are not presuming vm == ggtt).
>>
>> pin, ggtt->bind_vma, move_to_active(ggtt), unpin.
>>
>> And then hope we have the correct flushes in place for that to be
>> retired if nothing else is going on with that ggtt.
>
> New idea: Can't we make this work in an easier fashion by changing the
> vma we look up for the eb lists using the right gtt appropriate for
> the batch?
>
> Then (presuming all our code is clear of unnecessary (obj, vm) -> vma
> lookups) everything should Just Work, including grabing the gtt
> offset. Or am I just dreaming here? Of course a BUG_ON to check that
> vma->vm of the batch object points at the global gtt vm if we have a
> secure dispatch bb would still be dutiful.

Ok, I'm dreaming, or at least it's not that simple: We also need the
ppgtt binding for the non-CS access to the batch bo (like indirect
state and stuff). So could we instead just insert two vmas into the eb
lists, one for the ppgtt and one for the global gtt?

Of course that means we can only tackle this once we do have multiple vms.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux