Koenig, Christian
2019-Apr-09 13:39 UTC
[PATCH 00/15] Share TTM code among framebuffer drivers
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.