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
