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