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

From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
	"puck.chen@hisilicon.com" <puck.chen@hisilicon.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"z.liuxinliang@hisilicon.com" <z.liuxinliang@hisilicon.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"kong.kongxinwei@hisilicon.com" <kong.kongxinwei@hisilicon.com>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"zourongrong@gmail.com" <zourongrong@gmail.com>,
	"Zhang, Jerry" <Jerry.Zhang@amd.com>,
	"Koenig, Christian" <Christian.Koenig@amd.com>
Subject: Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Date: Mon, 15 Apr 2019 17:57:34 +0200	[thread overview]
Message-ID: <20190415155734.GC2665@phenom.ffwll.local> (raw)
In-Reply-To: <20190415155430.GB2665@phenom.ffwll.local>

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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel