[PATCH 0/9] drm: Support GEM SHMEM fbdev without shadow FB

Javier Martinez Canillas javierm at redhat.com
Tue Mar 8 09:13:44 UTC 2022


Hello Thomas,

On 3/3/22 21:58, Thomas Zimmermann wrote:
> Rework the fbdev deferred-I/O to not interfere with fields of struct
> page. Make the code more flexible and implement GEM SHMEM mmap on top
> of it.
> 
> This patchset removes the need for a special shadow framebuffer for
> fbdev mmap when using GEM SHMEM. SHMEM pages are now mmap'ed from
> /dev/fb directly.
>

Interesting. I wonder if you have any performance improvements after
dropping the shadow buffer.

> Patches 2 and 3 rework the fbdev deferred I/O code. It now allows
> drivers to have better control of the mmap operations. All references
> to fields in struct page are gone. The rsp state is help in a 
> separate pageref structure.
>

That's a very nice cleanup. This really was a huge layering violation.
 
> Patches 4 to 7 provide callbacks an helpers to implement deferred I/O
> with DRM drivers. Specifically, patch 6 introduces a callback to create
> a dumb buffer for fbdev. This will be useful for many drivers that
> currently cannot use generic fbdev emulation because of special placement
> needs of the BO, such as amdgpu or radeon. The drivers can handle the
> differences to regular dumb buffers in their new callback implementation.
> 
> Patch 8 extends the GEM SHMEM memory manager with a new helper for fbdev
> dumb-buffer creation. The returned BO has it's mmap set up to implement
> deferred I/O with SHMEM pages. No additional shadow buffer is requires
> any longer. Many drivers can immediatelly benefit from this change.
> 
> Patch 9 extends virtgpu to support fbdev dumb buffers. It's build on
> top of GEM SHMEM, but has some modifications that need to be implemented
> for fbdev as well.
> 
> There's no immediate fbdev performance improvement from this patchset.
> Most of all, it removes unnecessary shadow framebuffers and rsp memcpys.
> A shadow fb for a FullHD display is ~8 MiB, which we now save. The patches
> do reduce latency between drawing to the fbdev buffer to displaying
> on the screen. Watching a video on the fbdev console felt smoother and
> had less flickering.
>

Awesome. And you also answered here the question I had above.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat



More information about the dri-devel mailing list