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

[Alex Deucher]

On Wed, Mar 7, 2018 at 2:02 PM, Li, Samuel <Samuel.Li at amd.com> wrote:
> How about that, in my previous patches, it actually allows three scenarios,
> 1) VRAM as display buffer
> 2) GTT as display buffer
> 3) Mixed GTT/display buffer, as you have asked.
>
> I think the first step is to make the 2nd scenario work at optimal level. After that, if anyone wants to work the 3rd scenario, I have no objection at all.

Regardless of which scenarios we need to support, I think we also need
to really plumb this through to mesa however since user space is who
ultimately requests the location.  Overriding it in the kernel gets
tricky and can lead to ping-ponging as others have noted.  Better to
have user space know what chips support it or not and request display
buffers in GTT or VRAM from the start.

Alex

>
> Regards,
> Samuel Li
>
>
>> -----Original Message-----
>> From: Samuel Li [mailto:samuel.li at amd.com]
>> Sent: Wednesday, March 07, 2018 1:54 PM
>> To: Alex Deucher <alexdeucher at gmail.com>
>> Cc: Michel Dänzer <michel at daenzer.net>; Koenig, Christian
>> <Christian.Koenig at amd.com>; amd-gfx list <amd-gfx at lists.freedesktop.org>
>> Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support
>>
>> > You might also want to prefer VRAM, but also allow buffers to fall
>> > back to GTT if necessary.
>> For display buffer, this case seems not really attractive. When display buffer
>> changes between GTT and VRAM dynamically, our driver needs to adpat too,
>> which is hard to see the benefits and not really worth the effort.
>>
>> Sam
>>
>>
>>
>> On 2018-03-07 01:27 PM, Alex Deucher wrote:
>> > On Wed, Mar 7, 2018 at 1:18 PM, Samuel Li <samuel.li at amd.com> wrote:
>> >> I think it's not useful though. Think about that, SG display feature is
>> intended to use as less VRAM as possible. Will someone want a display
>> buffer sometimes VRAM, sometimes GTT?
>> >> Hardly a case to me, and I think it's a waste of effort. That also might
>> explain no driver does that now.
>> >
>> > You might want different strategies depending on how much VRAM you
>> > have.  If you have a bunch and it performs better, prefer it.  If you
>> > have limited VRAM, you might want to prefer GTT.  You might also want
>> > to prefer VRAM, but also allow buffers to fall back to GTT if
>> > necessary.  This would make the logic dynamic and all in one place.
>> > The kernel can advertise what asics support scanout from system ram
>> > and then UMDs can just query that to choose placements rather than
>> > adding hardcoded logic for specific asics.
>> >
>> > Alex
>> >
>> >>
>> >> Sam
>> >>
>> >>
>> >>
>> >> On 2018-03-07 12:50 PM, Michel Dänzer wrote:
>> >>> On 2018-03-07 06:38 PM, Alex Deucher wrote:
>> >>>> On Wed, Mar 7, 2018 at 12:29 PM, Samuel Li <samuel.li at amd.com>
>> wrote:
>> >>>>>
>> >>>>> Why so complicated? If old user space compatibility is required, just
>> use sg_display=0.
>> >>>>
>> >>>> It will always just work in that case and we can adjust for the
>> >>>> optimal scenario by default in all cases without requiring the user
>> >>>> to set misc parameters to tune their setup that may break in the
>> >>>> future or hide bugs because a user sets it and forgets it.
>> >>>
>> >>> Right. I don't agree it's all that complicated anyway, we do this
>> >>> sort of thing all the time, it also makes our lives easier down the road.
>> >>>
>> >>>