[Intel-gfx] [PATCH v2 02/15] drm/i915/dsb: DSB context creation.

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Thu Oct 17 14:38:39 UTC 2019


On 17/10/2019 14:53, Animesh Manna wrote:
> On 10/17/2019 6:39 PM, Tvrtko Ursulin wrote:
>> On 17/10/2019 13:52, Animesh Manna wrote:
>>> On 10/17/2019 2:05 PM, Tvrtko Ursulin wrote:
>>>> On 22/08/2019 13:09, Chris Wilson wrote:
>>>>> Quoting Animesh Manna (2019-08-22 13:05:06)
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> On 8/21/2019 11:41 PM, Chris Wilson wrote:
>>>>>>> Quoting Animesh Manna (2019-08-21 07:32:22)
>>>>>>>> +       vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 
>>>>>>>> PIN_MAPPABLE);
>>>>>>> Only this (currently) still requires struct_mutex
>>>>>>
>>>>>> Sure will add.
>>>>>>>
>>>>>>> Does it have to mappable? Is that the HW constraint?
>>>>>>
>>>>>> Yes, as per HW design need a cpu mapped buffer to write 
>>>>>> opcode+data from
>>>>>> driver.
>>>>>
>>>>> PIN_MAPPABLE refers to the iomem aperture portion of the Global GTT 
>>>>> (i.e.
>>>>> the low 64-512MiB). You never use a GGTT mmap for your CPU access, 
>>>>> so the
>>>>> placement should be entirely dictated by the DSB requirements. If you
>>>>> don't need to be in the low region, don't force it to be, so we have
>>>>> less congestion for the objects that have to be placed in that region.
>>>>
>>>> I was doing a mini audit of what uses the aperture these days and 
>>>> noticed this code has been merged in the meantime, but AFAICS this 
>>>> question from Chris hasn't been answered? At least not on the 
>>>> mailing list. So does it need to be in the aperture region or not?
>>>
>>> Hi,
>>>
>>> Based on recommendation from H/w team used PIN_MAPPABLE, not very 
>>> sure about internal details.
>>
>> What did the recommendation exactly say? That it has to be in GGTT or 
>> aperture?
> 
> It said:
> "GMM to allocate buffer from global GTT, get CPU mapped address as well 
> (not stolen memory) ... ".

So it's possible you don't need PIN_MAPPABLE.

Do we have some test coverage for this? In other words if I send a patch 
which removes it, will we know if the feature is healthy?

Regards,

Tvrtko


More information about the Intel-gfx mailing list