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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 21.03.2018 um 19:04 schrieb Marek Olšák:
> On Wed, Mar 21, 2018 at 10:07 AM, Christian König 
> <christian.koenig at amd.com <mailto:christian.koenig at amd.com>> wrote:
>
>     Am 21.03.2018 um 14:57 schrieb Marek Olšák:
>>     On Wed, Mar 21, 2018 at 4:13 AM, Christian König
>>     <ckoenig.leichtzumerken at gmail.com
>>     <mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
>>
>>         Am 21.03.2018 um 06:08 schrieb Marek Olšák:
>>>         On Tue, Mar 20, 2018 at 4:16 PM, Christian König
>>>         <christian.koenig at amd.com <mailto:christian.koenig at amd.com>>
>>>         wrote:
>>>
>>>             That's what I meant with use up the otherwise unused
>>>             VRAM. I don't see any disadvantage of always setting GTT
>>>             as second domain on APUs.
>>>
>>>             My assumption was that we dropped this in userspace for
>>>             displayable surfaces, but Marek proved that wrong.
>>>
>>>             So what we should do is actually to add GTT as fallback
>>>             to all BOs on APUs in Mesa and only make sure that the
>>>             kernel is capable of handling GTT with optimal
>>>             performance (e.g. have user huge pages etc..).
>>>
>>>
>>>         VRAM|GTT is practically as good as GTT. VRAM with BO
>>>         priorities and eviction throttling is the true "VRAM|GTT".
>>>
>>>         I don't know how else to make use of VRAM intelligently.
>>
>>         Well why not set VRAM|GTT as default on APUs? That should
>>         still save quite a bunch of moves even with throttling.
>>
>>
>>     I explained why: VRAM|GTT is practically as good as GTT.
>>
>>
>>         I mean there really shouldn't be any advantage to use VRAM
>>         any more except that we want to use it up as long as it is
>>         available.
>>
>>
>>     Why are you suggesting to use VRAM|GTT then? Let's just only use
>>     GTT on all APUs.
>
>     Then we don't use the memory stolen for VRAM.
>
>     See we want to get to a point where we have any ~16MB of stolen
>     VRAM on APUs and everything else in GTT.
>
>     But we still have to support cases where we have 1GB stolen VRAM,
>     and wasting those 1GB would suck a bit.
>
>
> BO priorities and BO move throttling should take care of optimal VRAM 
> usage regardless of the VRAM size. We can adjust the throttling for 
> small VRAM, but that's about all we can do.

Well at least on APUs move throttling is complete nonsense. VRAM should 
expose the same performance as GTT.

So the only usage we have for VRAM is for special cases like page tables 
and to allow to actually use the stolen memory.

> VRAM|GTT doesn't guarantee that VRAM will be used usefully. In fact, 
> it doesn't guarantee anything about VRAM.

Why not? VRAM|GTT means that we should use VRAM as long as it is 
available and if it is used up fallback to GTT.

When BOs are evicted from VRAM they are never moved back into it. As far 
as I can see that is exactly what we need on APUs.

Christian.

>
> Marek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180321/5aff12be/attachment-0001.html>


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux