[PATCH 1/2] drm/amdgpu: Enable scatter gather display support

[Marek Olšák]

On Mon, Mar 19, 2018 at 3:27 PM, Christian König <christian.koenig at amd.com>
wrote:

> I think that the consensus with Alex and me is that we should avoid
> exactly that.
>
> Overriding the preferred domain in the kernel is a no-go for that patch
> set, so please implement the discussed changes in Mesa.
>

I don't see how Mesa can make a smarter decision than the kernel. If you
overwrite the preferred domain of the buffer in the kernel, there will be
no ping-ponging between domains. Mesa never changes the initial preferred
domain.

Marek



>
> Regards,
> Christian.
>
>
> Am 19.03.2018 um 20:22 schrieb Li, Samuel:
>
>> I agree with Marek/Michel: since kernel sets the domain before scanning
>> out, it shall update the preferred domain here too.
>>
>> Regards,
>> Samuel Li
>>
>>
>> -----Original Message-----
>>> From: Koenig, Christian
>>> Sent: Thursday, March 08, 2018 4:07 AM
>>> To: Michel Dänzer <michel at daenzer.net>; Li, Samuel
>>> <Samuel.Li at amd.com>; Alex Deucher <alexdeucher at gmail.com>
>>> Cc: amd-gfx list <amd-gfx at lists.freedesktop.org>
>>> Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
>>> support
>>>
>>> Am 08.03.2018 um 09:35 schrieb Michel Dänzer:
>>>
>>>> On 2018-03-07 10:47 AM, Christian König wrote:
>>>>
>>>>> Am 07.03.2018 um 09:42 schrieb Michel Dänzer:
>>>>>
>>>>>> On 2018-03-06 07:23 PM, Christian König wrote:
>>>>>>
>>>>>> E.g. the last time I tested it placing things into GTT still
>>>>>>> resulted in quite a performance penalty for rendering.
>>>>>>>
>>>>>> FWIW, I think the penalty is most likely IOMMU related. Last time I
>>>>>> tested, I couldn't measure a big difference with IOMMU disabled.
>>>>>>
>>>>> No, the penalty I'm talking about came from the ping/pong we did with
>>>>> the scanout buffers.
>>>>>
>>>>> See when I tested this the DDX and Mesa where unmodified, so both
>>>>> still assumed VRAM as placement for scanout BOs, but the kernel
>>>>> forced scanout BOs into GTT for testing.
>>>>>
>>>>> So what happened was that on scanout we moved the VRAM BO to GTT
>>>>>
>>>> and
>>>
>>>> after unpinning it on the first command submission which used the BO
>>>>> we moved it back to VRAM again.
>>>>>
>>>> In the meantime, I've had the same idea as Marek: Can't the kernel
>>>> driver simply change the BO's preferred domain to GTT when scanning
>>>> out from it? Then it won't move back to VRAM.
>>>>
>>> Yes, I've considered this as well.
>>>
>>> But I think making the decision in Mesa is the cleaner approach.
>>>
>>> E.g. so far we only override the placement decision of userspace for two
>>> reasons:
>>> 1. We where running out of memory in VRAM.
>>> 2. We have a hardware restriction which makes VRAM usage mandatory.
>>>
>>> And even then we never adjust the placement permanently, we just
>>> temporary moved the buffer where it was needed and moved it back after
>>> the operation completed.
>>>
>>> Additional to that Mesa might want to set even more flags and/or changes
>>> it's behavior. E.g. use a tilling mode which both importer and export in
>>> an
>>> A+A laptop understands etc...
>>>
>>> Regards,
>>> Christian.
>>>
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180319/56740ea9/attachment.html>