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

Koenig, Christian
Tue, 09 Apr 2019 13:39:23 -0000

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.