| Message ID | 20220303205839.28484-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Support GEM SHMEM fbdev without shadow FB | expand |
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.
Hi Javier Am 08.03.22 um 10:13 schrieb Javier Martinez Canillas: > 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. There's no significant improvement in performance. But when I play Bug Buck Bunny in mplayer's benchmark mode, the displayed animation looks smoother than before. The test finishes in 73 seconds instead of 74. I guess that one-second improvement comes from the memcpy that we now save. I use a somewhat recent Core i7 for testing. On old hardware, we might get more performance out of it. I can really only guess here. Best regards Thomas >