[RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie airlied at gmail.com> wrote:
> On 10 December 2016 at 05:59, Daniel Vetter <daniel at ffwll.ch> wrote:
>> I guess things went a bit sideways by me and Dave only talking about
>> the midlayer, so let me first state that the DC stuff has massively
>> improved through replacing all the backend services that reimplemented
>> Linux helper libraries with their native equivalent. That's some
>> serious work, and it shows that AMD is committed to doing the right
>> thing.
>>
>> I absolutely didn't want to belittle all that effort by only raising
>> what I see is the one holdover left.
>
> I see myself and Daniel have kinda fallen into good-cop, bad-cop mode.
>
> I agree with everything Daniel had said in here, and come next week I might
> try and write something more constructive up, but believe me Daniel is totally
> right! It's Saturday morning, I've got a weekend to deal with and I'm going to
> try and avoid thinking too much about this.

Yeah I'm pondering what a reasonable action plan for dc from an atomic
pov is too. One issue we have is that right now the atomic docs are a
bit lacking for large-scale/design issues. But I'm working on this
(hopefully happens soonish, we need it for intel projects too), both
pulling the original atomic design stuff from my blog into docs and
beat into shape. And also how to handle state and atomic_check/commit
for when you want a state model that goes massively beyond what's
there with just drm_plane/crtc/connector_state (like e.g. i915 has).

But instead of me typing this up in this thread here and then getting
lost again (hopefully amdgpu/dc is not the last full-featured driver
we'll get ...) I think it's better if I type this up for the drm docs
and ask Harry/Tony&co for review feedback.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch