Hi Rob,
thanks for the heads-up for this. We're definitely interested in
contributing to proposed new frameworks.
I'm not sure we want to tightly couple userspace with hardware, though.
Your proposal seems to assume that user mode is responsible for knowing
how many planes any given configuration needs, or iterating through
failures until a successful solution is found. First this is quite
sub-optimal and would be hard to get right without duplicating most of
kernel driver resource management in user mode. Second this doesn't
solve the problem with fbcon or other solutions when there is no
user-mode component.
Cheers,
Harry
On 2016-02-14 08:32 AM, Rob Clark wrote:
On Fri, Feb 12, 2016 at 7:05 PM, Wentland, Harry <Harry.Wentland@xxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
