Thomas Zimmermann
2023-Mar-17 12:19 UTC
[PATCH 1/6] drm/fbdev-generic: Always use shadow buffering
Hi Javier Am 17.03.23 um 12:47 schrieb Javier Martinez Canillas:> Thomas Zimmermann <tzimmermann at suse.de> 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 at suse.de> >> --- > > It's much cleaner indeed to have fbdev-dma separated from fbdev-generic. > > Reviewed-by: Javier Martinez Canillas <javierm at redhat.com> >-- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20230317/ee4b2e28/attachment.sig>