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

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2880 bytes --]

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?

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@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel