Linux Virtualization - Apr 2019 - [PATCH 00/15] Share TTM code among framebuffer drivers

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

On Mon, Apr 15, 2019 at 05:54:30PM +0200, Daniel Vetter
wrote:
> 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
One more:

- Only bother supporting hw that needs contiguous scanout buffers in VRAM.
  I think hw that has pagetables for scanout (and everything else really)
  is sufficiently different that cramming them into the same helpers
  doesn't make much sense: You want to manage your VRAM with a buddy
  allocator at a page level, plus you need to manage your pagetables, and
  all is likely very hw specific anyway. Plus I haven't seen such hw that
  doesn't come with a real gpu attached :-)

-Daniel
> 
> 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch