[PATCH 00/15] Share TTM code among framebuffer drivers

[Daniel Vetter]

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com:
> >   Hi,
> > 
> >> If not for TTM, what would be the alternative? One VMA manager per
> >> memory region per device?
> > 
> > Depends pretty much on the device.
> > 
> > The cirrus is a display device with only 4 MB of vram.  You can't fit
> > much in there.  A single 1024x768 @ 24bpp framebuffer needs more 50%
> > of the video memory already.  Which is why the cirrus driver (before the
> > rewrite) had to migrate buffers from/to vram on every page flip[1].  Which
> > is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the
> > vram any more.  gem objects are managed with the shmem helpers instead
> > and the active framebuffer is blitted to vram.
> > 
> > The qemu stdvga (bochs driver) has 16 MB vram by default and can be
> > configured to have up to 256 MB.  Plenty of room even for multiple 4k
> > framebuffers if needed.  So for the bochs driver all the ttm bo
> > migration logic is not needed, it could just store everything in vram.
> > 
> > A set of drm_gem_vram_* helpers would do the job for bochs.
> 
> Thanks for clarifying. drm_gem_vram_* (and drm_vram_mm for Simple TTM)
> is probably a better name for the data structures.

+1 on drm_gem_vram_* naming convention - we want to describe what it's
for, not how it's implemented.

> > I'd expect the same applies to the vbox driver.
> > 
> > Dunno about the other drm drivers and the fbdev drivers you plan to
> > migrate over.
> 
> The AST HW can support up to 512 MiB, but 32-64 MiB seems more realistic
> for a server. It's similar with mgag200 HW. The old fbdev-supported
> device are all somewhere in the range between cirrus and bochs. Some
> drivers would probably benefit from the cirrus approach, some could use
> VRAM directly.

I think for dumb scanout with vram all we need is:
- pin framebuffers, which potentially moves the underlying bo into vram
- unpin framebuffers (which is just accounting, we don't want to move the
  bo on every flip!)
- if a pin doesn't find enough space, move one of the unpinned bo still
  resident in vram out
- no pipelining, no support for dma engines (it's all cpu copies anway)
- a simple drm_mm should be good enough to manage the vram, no need for
  the ttm style abstraction over how memory is manged
- also just bake in the lru eviction list and algorithm
- probably good to have built-in support for redirecting the mmap between
  shmem and iomem.
- anything that needs pipelining or copy engines would be out of scope for
  these helpers

I think for starting points we can go with a copypasted version of the
various ttm implementations we already have, and then simplify from there
as needed. Or just start fresh if that's too complicated, due to the issue
Christian highlighted.
-Daniel

> Best regards
> Thomas
> 
> > 
> > cheers,
> >   Gerd
> > 
> > [1] Note: The page-flip migration logic is present in some of the other
> >     drivers too, not sure whenever they actually need that due to being low
> >     on vram too or whenever they just copied the old cirrus code ...
> > 
> > [2] The other reason is that this allow to convert formats at blit time,
> >     which helps to deal with some cirrus hardware limitations.
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
> 




-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch