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 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
