[PATCH 1/6] drm/fbdev-generic: Always use shadow buffering

Thomas Zimmermann tzimmermann at suse.de
Fri Mar 17 12:19:55 UTC 2023


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: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230317/ee4b2e28/attachment-0001.sig>


More information about the dri-devel mailing list