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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux