Hi Am 19.09.19 um 07:58 schrieb Gerd Hoffmann: > On Wed, Sep 18, 2019 at 04:22:57PM +0200, Thomas Zimmermann wrote: >> Drivers with dedicated video memory occasionally need to reserve a memory >> area for a specific purpose, such as cursor images or sprites. Using GEM >> VRAM buffer objects can be problematic. For small buffers, GEM VRAM buffer >> objects are inefficient as they are aligned to page boundaries. > > I would still allocate gem objects for that. Then use them as pool > instead of using them directly. > > Not sure this is worth the trouble just for the cursors though as they > are big enough that page-sized allocations don't waste memory. > >> And they cannot easily be placed at specific memory offsets. This can >> lead to memory fragmentation and is a problem for hardware with only a >> small amount of memory. > > Note that there is a flag to change the allocation strategy > (TTM_PL_FLAG_TOPDOWN). You could allocate the cursor objects > with the flag set. Should be good enough to avoid fragmentation. > > I have a patch doing exactly that for qxl, for the same reason: > https://git.kraxel.org/cgit/linux/commit/?id=e00e913a64c6fba9630b311f8bc71bd7c9842479 > (no, that patch wasn't sent to the list yet). > > We could do the same for vram and either let the driver explicitly ask > for top-down allocation, or use some threshold like the qxl patch. > > So, I'm not convinced we actually need the drm_vram_buffer > infrastructure. Well, OK. I don't mind using GEM buffers if they can solve the problem. Half of the patch set is unrelated to VRAM buffers anyway. Best regards Thomas > > cheers, > Gerd > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
