From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 00/15] Share TTM code among framebuffer drivers Date: Tue, 16 Apr 2019 13:03:28 +0200 Message-ID: References: <20190408092144.4548-1-tzimmermann@suse.de> <096a70a7-ed24-2161-29e9-1907221b8a64@suse.de> <20190409071249.ngzarvjlztx4jwbh@sirius.home.kraxel.org> <20190415155430.GB2665@phenom.ffwll.local> <9a3af097-d907-30da-73db-bcf00223e70b@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9a3af097-d907-30da-73db-bcf00223e70b@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "Koenig, Christian" Cc: "airlied@linux.ie" , "puck.chen@hisilicon.com" , "Zhang, Jerry" , "dri-devel@lists.freedesktop.org" , "virtualization@lists.linux-foundation.org" , "z.liuxinliang@hisilicon.com" , "hdegoede@redhat.com" , "kong.kongxinwei@hisilicon.com" , "Huang, Ray" , Thomas Zimmermann , "zourongrong@gmail.com" List-Id: virtualization@lists.linuxfoundation.org On Tue, Apr 16, 2019 at 12:05 PM Koenig, Christian wrote: > > Am 15.04.19 um 21:17 schrieb Daniel Vetter: > > On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann 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: > >>>> [SNIP] > >>>>> 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. > > Well how about making an drm_lru component which just does the following > (and nothing else, please :): > > 1. Keep a list of objects and a spinlock protecting the list. > > 2. Offer helpers for adding/deleting/moving stuff from the list. > > 3. Offer a functionality to do the necessary dance of picking the first > entry where we can trylock it's reservation object. > > 4. Offer bulk move functionality similar to what TTM does at the moment > (can be implemented later on). At a basic level, this is list_head of drm_gem_object. Not sure that's all that useful (outside of the fairly simplistic vram helpers we're discussing here). Reasons for that is that there's a lot of trickery in selecting which is the best object to pick in any given case (e.g. do you want to use drm_mm scanning, or is there a slab of objects you prefer to throw out because that avoids. Given that I'm not sure implementing the entire scanning/drm_lru logic is beneficial. The magic trylock+kref_get_unless_zero otoh could be worth implementing as a helper, together with a note about how to build your own custom lru algorithm. Same for some bulk/nonblocking movement helpers maybe. Both not really needed for the dumb scanout vram helpers we're discussing here. -Daniel -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch