[PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

[Rob Clark]

On Fri, Feb 12, 2016 at 7:05 PM, Wentland, Harry <Harry.Wentland at amd.com> wrote:
>
> The current amdgpu display stack grew somewhat organically and as such is not well suited to handling all of the hardware dependencies involved especially in areas like audio.  The drm abstractions used by the old code map less and less well to new hw pipelines.  Atomic helps, but if we are going to convert, it seemed like a good time to start fresh.
>
> Our DC (Display Core in dc.h, etc.) is the framework to allow us to well represent current and future HW architectures. These don't always map one-to-one to DRM interfaces. For one we can't make the assumption that surfaces map one-to-one to pipes.

So, this sounds a bit vaguely like some things that I have discussed
from drm/msm.. where you might end up using multiple planes to scan
out a single surface, or multiplex a single plane between multiple
surfaces (or combinations thereof)..

I think what we'll end up doing is virtualizing planes so we advertise
to userspace more planes than actually exist, and at atomic update
time, dynamically assign pipes to planes, and reject things if
userspace asks for too many planes..  although this is getting into an
area where it helps to assume that there is a userspace component
which is familiar with your hw, which is true for android (and I think
some day wayland compositors will have to grow similar capability for
driver specific userspace plugin to make decisions about how to assign
planes).

Not sure if a similar approach would help you to fit better into the
kms/atomic framework?

BR,
-R