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

[Christian König]

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.

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.