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@xxxxxxxxxx: > > > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
