Hi Javier Am 17.03.23 um 12:47 schrieb Javier Martinez Canillas:
Thomas Zimmermann <tzimmermann@xxxxxxx> writes: Hello Thomas,Remove all codepaths that implement fbdev output directly on GEM buffers. Always allocate a shadow buffer in system memory and set up deferred I/O for mmap. The fbdev code that operated directly on GEM buffers was used by drivers based on GEM DMA helpers. Those drivers have been migrated to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All remaining users of fbdev-generic require shadow buffering. Memory management of the remaining callers uses TTM, GEM SHMEM helpers or a variant of GEM DMA helpers that is incompatible with fbdev-dma. Therefore remove the unused codepaths from fbdev-generic and simplify the code. Using a shadow buffer with deferred I/O is probably the best case for most remaining callers. Some of the TTM-based drivers might benefit from a dedicated fbdev emulation that operates directly on the driver's video memory.But it's questionable if that would be useful due the limited ammount of video memory that most of the devices using TTM-based drivers have, right?
Right. The main reason for using VRAM directly is performance. I've seen complains about the console performance with nouveau after they switched to fbdev-generic. Some drivers and/or hardware had acceleration for the console that could also be utilized. Of course, this requires a certain amount of video ram dedicated to the fbdev layer.
The other reason is the VGA swicheroo, which is currently hacked into the fbdev helpers. Only a few drivers need it, so having it in separate fbbev emulation for each driver would be nice.
Best regards Thomas
Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx> ---It's much cleaner indeed to have fbdev-dma separated from fbdev-generic. Reviewed-by: Javier Martinez Canillas <javierm@xxxxxxxxxx>
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
