[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