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

From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: "Cheng, Tony" <Tony.Cheng@amd.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Lysenko, Mykola" <Mykola.Lysenko@amd.com>
Subject: Re: [PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga
Date: Sun, 14 Feb 2016 14:51:45 +0100	[thread overview]
Message-ID: <CAKMK7uEc_pEzUmGW2+fmc4ToCWTRPt+53L-Qw+FVxHqzm7NYFA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGshdCfgSSHeUWEBOvF4B2ADv7GL8po-PEpQWsp0jhgBZg@mail.gmail.com>

On Sun, Feb 14, 2016 at 2:32 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Fri, Feb 12, 2016 at 7:05 PM, Wentland, Harry <Harry.Wentland@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?

Hm, maybe I misread the code and the diagram, but to me it looked like
dc_surface == drm_plane. And you can already freely assign drm_planes
to display pipelines (represented by drm_crtc). That's btw also the
part where your atomic driver seems to seriously mismatch how drm
atomic is meant to be used, since you dig out the connector state when
commit plane states, which is a no-go.

dc_target otoh seems to not entirely match to drm_crtc, and contain
some of drm_display_info and drm_connector stuff too. At least from
cursory reading around in the code.

So not sure how this should all map, but like Rob said you can
internally virtualize stuff if really needed. But then you should
still pass around drm_plane_state in your low-level hw commit
functions and not dal-private structures to avoid the midlayer issues.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel