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

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 15.04.19 um 17:54 schrieb 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@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.
>
> OK, great.
>
> >>> 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
>
> For dumb buffers, I'd expect userspace to have a working set of only a
> front and back buffer (plus maybe a third one). This working set has to
> reside in VRAM for performance reasons; non-WS BOs from other userspace
> programs don't have to be.
>
> So we could simplify even more: if there's not enough free space in
> vram, remove all unpinned BO's. This would avoid the need to implement
> an LRU algorithm or another eviction strategy. Userspace with a WS
> larger than the absolute VRAM would see degraded performance but
> otherwise still work.

You still need a list of unpinned bo, and the lru scan algorithm is
just a few lines of code more than unpinning everything. Plus it'd be
a neat example of the drm_mm scan logic. Given that some folks might
think that not having lru evict si a problem and get them to type
their own, I'd just add it. But up to you. Plus with ttm you get it no
matter what.
-Daniel


> Best regards
> Thomas
>
> > - 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)
> >>
> >
> >
> >
> >
>
> --
> 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
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization