[PATCH libdrm] amdgpu: add a faster BO list API

[Marek Olšák]

FYI, I've pushed the patch because it helps simplify our the amdgpu winsys
code and I already have code that depends on it that I don't wanna rewrite.

Marek

On Wed, Jan 16, 2019 at 12:39 PM Marek Olšák <maraeo at gmail.com> wrote:

> On Wed, Jan 16, 2019 at 9:43 AM Christian König <
> ckoenig.leichtzumerken at gmail.com> wrote:
>
>> Am 16.01.19 um 15:39 schrieb Marek Olšák:
>>
>>
>>
>> On Wed, Jan 16, 2019, 9:34 AM Koenig, Christian <Christian.Koenig at amd.com
>> wrote:
>>
>>> Am 16.01.19 um 15:31 schrieb Marek Olšák:
>>>
>>>
>>>
>>> On Wed, Jan 16, 2019, 7:55 AM Christian König <
>>> ckoenig.leichtzumerken at gmail.com wrote:
>>>
>>>> Well if you ask me we should have the following interface for
>>>> negotiating memory management with the kernel:
>>>>
>>>> 1. We have per process BOs which can't be shared between processes.
>>>>
>>>> Those are always valid and don't need to be mentioned in any BO list
>>>> whatsoever.
>>>>
>>>> If we knew that a per process BO is currently not in use we can
>>>> optionally tell that to the kernel to make memory management more
>>>> efficient.
>>>>
>>>> In other words instead of a list of stuff which is used we send down to
>>>> the kernel a list of stuff which is not used any more and that only
>>>> when
>>>> we know that it is necessary, e.g. when a game or application
>>>> overcommits.
>>>>
>>>
>>> Radeonsi doesn't use this because this approach caused performance
>>> degradation and also drops BO priorities.
>>>
>>>
>>> The performance degradation where mostly shortcomings with the LRU which
>>> by now have been fixed.
>>>
>>> BO priorities are a different topic, but could be added to per VM BOs as
>>> well.
>>>
>>
>> What's the minimum drm version that contains the fixes?
>>
>>
>> I've pushed the last optimization this morning. No idea when it really
>> became useful, but the numbers from the closed source clients now look much
>> better.
>>
>> We should probably test and bump the drm version when we are sure that
>> this now works as expected.
>>
>
> We should, but AMD Mesa guys don't have any time.
>
> Marek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20190116/254d172a/attachment.html>