[Intel-gfx] [PATCH 06/26] drm/i915: Parse command buffer earlier in eb_relocate(slow)

[Maarten Lankhorst]

Op 29-06-2020 om 13:15 schreef Thomas Hellström (Intel):
> Hi,
>
> On 6/29/20 12:40 PM, Maarten Lankhorst wrote:
>>
>>>>        /*
>>>>         * snb/ivb/vlv conflate the "batch in ppgtt" bit with the "non-secure
>>>>         * batch" bit. Hence we need to pin secure batches into the global gtt.
>>>>         * hsw should have this fixed, but bdw mucks it up again. */
>>>> -    batch = eb.batch->vma;
>>>>        if (eb.batch_flags & I915_DISPATCH_SECURE) {
>>>>            struct i915_vma *vma;
>>>>    @@ -2923,13 +2927,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
>>>>             *   fitting due to fragmentation.
>>>>             * So this is actually safe.
>>>>             */
>>>> -        vma = i915_gem_object_ggtt_pin(batch->obj, NULL, 0, 0, 0);
>>>> +        vma = i915_gem_object_ggtt_pin(eb.batch->vma->obj, NULL, 0, 0, 0);
>>>>            if (IS_ERR(vma)) {
>>>>                err = PTR_ERR(vma);
>>>>                goto err_parse;
>>>>            }
>>>>              batch = vma;
>>>> +    } else {
>>>> +        batch = eb.batch->vma;
>>>>        }
>>>>    
>>> Hmm, it's late friday afternoon so that might be the cause, but I fail to see what the above hunk is trying to achieve?
>>
>> Execbuf parsing may create a shadow object which also needs to be locked, we do this inside eb_relocate() to ensure the normal rules for w/w handling can be used for eb parsing as well. :)
>>
>> ~Maarten
>
> I meant the changed assignment of the batch variable?
>
> /Thomas
>
>
Nothing, still ends up being the same. :)

Was looking at changing that pin as well, didn't get around to it yet.

~Maarten