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

From: "Koenig, Christian" <Christian.Koenig@amd.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	"Zhang, Jerry" <Jerry.Zhang@amd.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"z.liuxinliang@hisilicon.com" <z.liuxinliang@hisilicon.com>,
	"zourongrong@gmail.com" <zourongrong@gmail.com>,
	"kong.kongxinwei@hisilicon.com" <kong.kongxinwei@hisilicon.com>,
	"puck.chen@hisilicon.com" <puck.chen@hisilicon.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Date: Tue, 9 Apr 2019 13:39:23 +0000	[thread overview]
Message-ID: <dd7affb9-4aa0-8f39-8937-e89e7cc8283c@amd.com> (raw)
In-Reply-To: <096a70a7-ed24-2161-29e9-1907221b8a64@suse.de>

Am 08.04.19 um 13:59 schrieb Thomas Zimmermann:
[SNIP]
> If not for TTM, what would be the alternative? One VMA manager per
> memory region per device?

Since everybody vital seems to be on this mail thread anyway, let's use 
it a bit for brain storming what a possible replacement for TTM should 
look like.

Well for simple drivers like qemu/bochs and cirrus the answer is to not 
use it at all. E.g. VRAM is only used for scanout and unprivileged 
userspace should not mess with it at all. In this case we don't need 
dynamic eviction and so also don't need TTM.

That leaves us with the more complex drivers, like radeon, amdgpu, 
nouveu and maybe some of the ARM based stuff, with vmwgfx being a bit 
special here.

Now I can summarize the requirements for at least the amdgpu in the 
following way:
1. We need to be able to allocate memory objects in different locations.
2. We need to be able to move around memory objects between different 
locations.
3. We need some LRU component which tells us what to evict when memory 
in a location becomes to tight.

Now for lessons learned we should at least avoid the following design 
pitfalls:
A) DON'T make it a layered design! Layers are for making cake, not software.

B) DON'T make it a "Eierlegende Wollmilchsau" (German saying). E.g. 
don't try to solve every single corner cases in one piece of software.
     Let's make components which solve one specific problem.

C) Pipeline everything! E.g. the hardware we deal with is asynchronous 
by design. Blocking for the hardware to finish in the common components 
itself is an absolutely no-go.
     If a driver wants to do something synchronous it should wait itself.

Those comments where not really intended for you Thomas, but I had to 
write them down somewhere :)

Regards,
Christian.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization