[PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement

[Christian König]

Am 24.04.20 um 09:03 schrieb Thomas Zimmermann:
> Hi
>
> Am 24.04.20 um 08:56 schrieb Christian König:
>> Am 24.04.20 um 08:27 schrieb Thomas Zimmermann:
>>> Hi Christian
>>>
>>> Am 23.04.20 um 17:04 schrieb Christian König:
>>>> Hi guys,
>>>>
>>>> one thing you don't seem to have considered yet is that not setting the
>>>> top-down flag also won't get you the bottom-up approach, but rather the
>>>> best fit.
>>> Kind of unrelated: Would it pick the smallest free area that can hold a
>>> BO? IOW, would a small cursor BO fill up a small free area even if
>>> there's a much larger free area somewhere?
>> Yes, exactly that.
> I see.
>
>> The bottom-up method searches for the lowest hole which can fit the
>> requirements.
> But there's no way to explictely select bottom-up? What is
> TTM_PL_FLAG_CONTIGUOUS doing?

Making sure that we allocate contiguous for amdgpu. Added that because I 
couldn't fix a few problems otherwise.

Should probably be a driver private placement flag instead, but didn't 
had time to clean that up.

Regards,
Christian.

>
> Best regards
> Thomas
>
>
>> The top-down method searches for the highest hole which can fit the
>> requirements.
>>
>> Both of those walk the holes by the address index tree, but there is
>> also the best method which looks at the holes by their size and tries to
>> find the best fit.
>>
>> The best method usually only needs a single tree walk instead of a
>> linear search.
>>
>>>> Am 23.04.20 um 15:57 schrieb Gerd Hoffmann:
>>>>>> But cursor BOs are small, so they don't make much of a difference.
>>>>>> What
>>>>>> is needed is space for 2 primary framebuffers during pageflips,
>>>>>> with one
>>>>>> of them pinned. The other framebuffer can be located anywhere.
>>>>> The problem isn't the size.  The problem is dynamically allocated
>>>>> cursor
>>>>> BOs can also fragment vram, especially if top-bottom allocation is also
>>>>> used for large framebuffers so cursor BOs can end up somewhere in the
>>>>> middle of vram.
>>>> Well maybe instead of a ping/pong approach between top and bottom use a
>>>> size based approach to place small BOs at the top and only the larger
>>>> ones at the bottom (or the other way around).
>>> That's what the current code does and it results in the OOM. Basically,
>>> there's a large BO in the middle of vram and the pageflip's destination
>>> BO does not fit before or after the large one.
>> Tough problem. No idea how to otherwise fix this without making the
>> large BO moveable somehow.
>>
>> Christian.
>>
>>> Best regards
>>> Thomas
>>>
>>>> Cheers,
>>>> Christian.
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel