RE: [RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

Thanks Alex my reply was a little off topic :)

-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com] 
Sent: Wednesday, December 14, 2016 1:02 PM
To: Cheng, Tony <tony.ch...@amd.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>; Lukas Wunner <lu...@wunner.de>; 
Bridgman, John <john.bridg...@amd.com>; Deucher, Alexander 
<alexander.deuc...@amd.com>; Grodzovsky, Andrey <andrey.grodzov...@amd.com>; 
amd-gfx mailing list <amd-gfx@lists.freedesktop.org>; dri-devel 
<dri-de...@lists.freedesktop.org>
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU

On Wed, Dec 14, 2016 at 12:23 PM, Cheng, Tony <tony.ch...@amd.com> wrote:
>
>
> On 12/14/2016 4:57 AM, Jani Nikula wrote:
>>
>> On Tue, 13 Dec 2016, "Cheng, Tony" <tony.ch...@amd.com> wrote:
>>>
>>> I am struggling with that these comminty contributions to DC would be.
>>>
>>> Us AMD developer has access to HW docs and designer and we are still 
>>> spending 50% of our time figuring out why our HW doesn't work right. 
>>> I can't image community doing much of this heavy lifting.
>>
>> I can sympathize with that view, and certainly most of the heavy 
>> lifting would come from you, same as with us and i915. However, when 
>> you put together your hardware, an open source driver, and smart 
>> people, they
>> *will* scratch their itches, whether they're bugs you're not fixing 
>> or features you're missing. Please don't underestimate and patronize 
>> them, it's going to rub people the wrong way.
>
> I aplogize if my statement offended any one in the community.  I'll 
> say more about bugs below.
>>>
>>> Dave sent us series of patch to show how it would look like if 
>>> someone were to change DC.  These changes are more removing code 
>>> that DRM already has and deleting/clean up stuff.  I guess we can 
>>> nak all changes and "rewrite" our own version of clean up patch community 
>>> want to see?
>>
>> Please have a look at, say,
>>
>> $ git shortlog -sne --since @{1year} -- drivers/gpu/drm/amd | grep -v 
>> amd\.com
>>
>> Do you really want to actively discourage all of them from contributing?
>> I think this would be detrimental to not only your driver, but the 
>> whole drm community. It feels like you'd like to have your code 
>> upstream, but still retain ownership as if it was in your internal 
>> repo. You can't have your cake and eat it too.
>
> That's none "dal" path.  It's just Alex plus a handful of guys trying 
> to figure out what register writes is needed base on windows driver.  
> You knwo who has been contributing to that code path from AMD and we 
> know it's a relatively small group of people.  Alex and team does 
> great job at being good citizen on linux world and provide support. 
> But in terms of HW programming and fully expolit our HW that's pretty 
> much the best they can do with the resource constraint.  Of course the 
> quality is not as good as we would like thus we needed all the help we 
> can get from community.  We just don't have the man power to make it great.
>
> We are proposing to get on a path where we can fully leverage the 
> coding and validation resources from rest of AMD Display teams (SW, 
> HW, tuning, validation, QA etc).  Our goal is to provide a driver to 
> linux community that's feature rich and high quality.  My goal is 
> community finds 0 bug in our code because we should've seen and fixed 
> those bug in our validation pass before we release the GPUs. We do 
> have a good size team around validation, just today that validation covers 0% 
> of upstream source code.
> Alex and I are trying to find a path to get these goodies on the 
> upstream driver without 2x size of our teams.  We know 2x our team 
> size is not an option.
>
> I just want to say I understand were community is coming from.  Like I 
> said in my first respond to Dave that I would've say no if someone 
> want to throw 100k lines of code into project (DAL) I have to maintain 
> without knowning what's there and the benefit we are getting.  We 
> already made a lot of change and design choice in our code base to 
> play well with community and absorbing the effort to restructure code 
> on other platforms as result of these modification.  We are going to 
> continue making more modifications to make our code linux worthy base on the 
> good feedback we have gotten so far.
>
> DAL3/DC is a new project we started a little over years ago and still 
> early enough stage to make changes.  Like how community is pushing 
> back on our code, after 1 or 2 future generation of GPU buil

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Alex Deucher]

On Wed, Dec 14, 2016 at 12:23 PM, Cheng, Tony  wrote:
>
>
> On 12/14/2016 4:57 AM, Jani Nikula wrote:
>>
>> On Tue, 13 Dec 2016, "Cheng, Tony"  wrote:
>>>
>>> I am struggling with that these comminty contributions to DC would be.
>>>
>>> Us AMD developer has access to HW docs and designer and we are still
>>> spending 50% of our time figuring out why our HW doesn't work right. I
>>> can't image community doing much of this heavy lifting.
>>
>> I can sympathize with that view, and certainly most of the heavy lifting
>> would come from you, same as with us and i915. However, when you put
>> together your hardware, an open source driver, and smart people, they
>> *will* scratch their itches, whether they're bugs you're not fixing or
>> features you're missing. Please don't underestimate and patronize them,
>> it's going to rub people the wrong way.
>
> I aplogize if my statement offended any one in the community.  I'll say more
> about bugs below.
>>>
>>> Dave sent us series of patch to show how it would look like if someone
>>> were to change DC.  These changes are more removing code that DRM
>>> already has and deleting/clean up stuff.  I guess we can nak all changes
>>> and "rewrite" our own version of clean up patch community want to see?
>>
>> Please have a look at, say,
>>
>> $ git shortlog -sne --since @{1year} -- drivers/gpu/drm/amd | grep -v
>> amd\.com
>>
>> Do you really want to actively discourage all of them from contributing?
>> I think this would be detrimental to not only your driver, but the whole
>> drm community. It feels like you'd like to have your code upstream, but
>> still retain ownership as if it was in your internal repo. You can't
>> have your cake and eat it too.
>
> That's none "dal" path.  It's just Alex plus a handful of guys trying to
> figure out what register writes is needed base on windows driver.  You knwo
> who has been contributing to that code path from AMD and we know it's a
> relatively small group of people.  Alex and team does great job at being
> good citizen on linux world and provide support. But in terms of HW
> programming and fully expolit our HW that's pretty much the best they can do
> with the resource constraint.  Of course the quality is not as good as we
> would like thus we needed all the help we can get from community.  We just
> don't have the man power to make it great.
>
> We are proposing to get on a path where we can fully leverage the coding and
> validation resources from rest of AMD Display teams (SW, HW, tuning,
> validation, QA etc).  Our goal is to provide a driver to linux community
> that's feature rich and high quality.  My goal is community finds 0 bug in
> our code because we should've seen and fixed those bug in our validation
> pass before we release the GPUs. We do have a good size team around
> validation, just today that validation covers 0% of upstream source code.
> Alex and I are trying to find a path to get these goodies on the upstream
> driver without 2x size of our teams.  We know 2x our team size is not an
> option.
>
> I just want to say I understand were community is coming from.  Like I said
> in my first respond to Dave that I would've say no if someone want to throw
> 100k lines of code into project (DAL) I have to maintain without knowning
> what's there and the benefit we are getting.  We already made a lot of
> change and design choice in our code base to play well with community and
> absorbing the effort to restructure code on other platforms as result of
> these modification.  We are going to continue making more modifications to
> make our code linux worthy base on the good feedback we have gotten so far.
>
> DAL3/DC is a new project we started a little over years ago and still early
> enough stage to make changes.  Like how community is pushing back on our
> code, after 1 or 2 future generation of GPU built on top of DC, the AMD
> teams on rest of platforms will start pushing back on changes in DC.  We
> need find find the balance of what's HW and what's core and how to draw the
> line so community doesn't make much modification in what we (both AMD and
> community) deem "hardware backend code".  We need to have the linux coding
> style and design principals baked in DC code so when our internal teams
> contribute to DC the code is written in a form linux community can accept.
> All of this need to happen soon or we miss this critical inflection point
> and it's going to be anther 6-8 years before we get another crack at
> re-archiecture project to try getting the rest of extended AMD display teams
> behind our upstream driver.

I think the point is that there are changes that make sense and
changes that don't If they make sense, we'll definitely take them.
Removing dead code or duplicate defines makes sense.  Rearranging a
propgramming sequence so all registers that start with CRTC_ get
programmed at the same time just because it looks logical does not
make sense.

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Alex Deucher]

On Tue, Dec 13, 2016 at 7:22 AM, Daniel Stone  wrote:
> Hi Harry,
> I've been loathe to jump in here, not least because both cop roles
> seem to be taken, but ...
>
> On 13 December 2016 at 01:49, Harry Wentland  wrote:
>> On 2016-12-11 09:57 PM, Dave Airlie wrote:
>>> On 8 December 2016 at 12:02, Harry Wentland  wrote:
>>> Sharing code is a laudable goal and I appreciate the resourcing
>>> constraints that led us to the point at which we find ourselves, but
>>> the way forward involves finding resources to upstream this code,
>>> dedicated people (even one person) who can spend time on a day by day
>>> basis talking to people in the open and working upstream, improving
>>> other pieces of the drm as they go, reading atomic patches and
>>> reviewing them, and can incrementally build the DC experience on top
>>> of the Linux kernel infrastructure. Then having the corresponding
>>> changes in the DC codebase happen internally to correspond to how the
>>> kernel code ends up looking. Lots of this code overlaps with stuff the
>>> drm already does, lots of is stuff the drm should be doing, so patches
>>> to the drm should be sent instead.
>>
>> Personally I'm with you on this and hope to get us there. I'm learning...
>> we're learning. I agree that changes on atomic, removing abstractions, etc.
>> should happen on dri-devel.
>>
>> When it comes to brand-new technologies (MST, Freesync), though, we're often
>> the first which means that we're spending a considerable amount of time to
>> get things right, working with HW teams, receiver vendors and other partners
>> internal and external to AMD. By the time we do get it right it's time to
>> hit the market. This gives us fairly little leeway to work with the
>> community on patches that won't land in distros for another half a year.
>> We're definitely hoping to improve some of this but it's not easy and in
>> some case impossible ahead of time (though definitely possibly after initial
>> release).
>
> Speaking with my Wayland hat on, I think these need to be very
> carefully considered. Both MST and FreeSync have _significant_ UABI
> implications, which may not be immediately obvious when working with a
> single implementation. Having them working and validated with a
> vertical stack of amdgpu-DC/KMS + xf86-video-amdgpu +
> Mesa-amdgpu/AMDGPU-Pro is one thing, but looking outside the X11 world
> we now have Weston, Mutter and KWin all directly driving KMS, plus
> whatever Mir/Unity ends up doing (presumably the same), and that's
> just on the desktop. Beyond the desktop, there's also CrOS/Freon and
> Android/HWC. For better or worse, outside of Xorg and HWC, we no
> longer have a vendor-provided userspace component driving KMS.
>
> It was also easy to get away with loose semantics before with X11
> imposing little to no structure on rendering, but we now have the twin
> requirements of an atomic and timing-precise ABI - see Mario Kleiner's
> unending quest for accuracy - and also a vendor-independent ABI. So a
> good part of the (not insignificant) pain incurred in the atomic
> transition for drivers, was in fact making those drivers conform to
> the expectations of the KMS UABI contract, which just happened to not
> have been tripped over previously.
>
> Speaking with my Collabora hat on now: we did do a substantial amount
> of demidlayering on the Exynos driver, including an atomic conversion,
> on Google's behalf. The original Exynos driver happened to work with
> the Tizen stack, but ChromeOS exposed a huge amount of subtle
> behaviour differences between that and other drivers when using Freon.
> We'd also hit the same issues when attempting to use Weston on Exynos
> in embedded devices for OEMs we worked with, so took on the project to
> remove the midlayer and have as much as possible driven from generic
> code.
>
> How the hardware is programmed is of course ultimately up to you, and
> in this regard AMD will be very different from Intel is very different
> from Nouveau is very different from Rockchip. But especially for new
> features like FreeSync, I think we need to be very conscious of
> walking the line between getting those features in early, and setting
> unworkable UABI in stone. It would be unfortunate if later on down the
> line, you had to choose between breaking older xf86-video-amdgpu
> userspace which depended on specific behaviours of the amdgpu kernel
> driver, or breaking the expectations of generic userspace such as
> Weston/Mutter/etc.

For clarity, as Michel said, the freesync stuff we have in the pro
driver is not indented for upstream in either the kernel or the
userspace.  It's a short term solution for short term deliverables.
That said, I think it's also useful to have something developers in
the community can test and play with to get a better understanding of
what use cases make sense when designing and validating the upstream
solution.

Alex

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

On 2016-12-13 08:50 PM, Michel Dänzer wrote:

On 13/12/16 09:59 PM, Daniel Vetter wrote:

On Tue, Dec 13, 2016 at 12:22:59PM +, Daniel Stone wrote:

Hi Harry,
I've been loathe to jump in here, not least because both cop roles
seem to be taken, but ...

On 13 December 2016 at 01:49, Harry Wentland  wrote:

On 2016-12-11 09:57 PM, Dave Airlie wrote:

On 8 December 2016 at 12:02, Harry Wentland  wrote:
Sharing code is a laudable goal and I appreciate the resourcing
constraints that led us to the point at which we find ourselves, but
the way forward involves finding resources to upstream this code,
dedicated people (even one person) who can spend time on a day by day
basis talking to people in the open and working upstream, improving
other pieces of the drm as they go, reading atomic patches and
reviewing them, and can incrementally build the DC experience on top
of the Linux kernel infrastructure. Then having the corresponding
changes in the DC codebase happen internally to correspond to how the
kernel code ends up looking. Lots of this code overlaps with stuff the
drm already does, lots of is stuff the drm should be doing, so patches
to the drm should be sent instead.


Personally I'm with you on this and hope to get us there. I'm learning...
we're learning. I agree that changes on atomic, removing abstractions, etc.
should happen on dri-devel.

When it comes to brand-new technologies (MST, Freesync), though, we're often
the first which means that we're spending a considerable amount of time to
get things right, working with HW teams, receiver vendors and other partners
internal and external to AMD. By the time we do get it right it's time to
hit the market. This gives us fairly little leeway to work with the
community on patches that won't land in distros for another half a year.
We're definitely hoping to improve some of this but it's not easy and in
some case impossible ahead of time (though definitely possibly after initial
release).


Speaking with my Wayland hat on, I think these need to be very
carefully considered. Both MST and FreeSync have _significant_ UABI
implications, which may not be immediately obvious when working with a
single implementation. Having them working and validated with a
vertical stack of amdgpu-DC/KMS + xf86-video-amdgpu +
Mesa-amdgpu/AMDGPU-Pro is one thing, but looking outside the X11 world
we now have Weston, Mutter and KWin all directly driving KMS, plus
whatever Mir/Unity ends up doing (presumably the same), and that's
just on the desktop. Beyond the desktop, there's also CrOS/Freon and
Android/HWC. For better or worse, outside of Xorg and HWC, we no
longer have a vendor-provided userspace component driving KMS.

It was also easy to get away with loose semantics before with X11
imposing little to no structure on rendering, but we now have the twin
requirements of an atomic and timing-precise ABI - see Mario Kleiner's
unending quest for accuracy - and also a vendor-independent ABI. So a
good part of the (not insignificant) pain incurred in the atomic
transition for drivers, was in fact making those drivers conform to
the expectations of the KMS UABI contract, which just happened to not
have been tripped over previously.

Speaking with my Collabora hat on now: we did do a substantial amount
of demidlayering on the Exynos driver, including an atomic conversion,
on Google's behalf. The original Exynos driver happened to work with
the Tizen stack, but ChromeOS exposed a huge amount of subtle
behaviour differences between that and other drivers when using Freon.
We'd also hit the same issues when attempting to use Weston on Exynos
in embedded devices for OEMs we worked with, so took on the project to
remove the midlayer and have as much as possible driven from generic
code.

How the hardware is programmed is of course ultimately up to you, and
in this regard AMD will be very different from Intel is very different
from Nouveau is very different from Rockchip. But especially for new
features like FreeSync, I think we need to be very conscious of
walking the line between getting those features in early, and setting
unworkable UABI in stone. It would be unfortunate if later on down the
line, you had to choose between breaking older xf86-video-amdgpu
userspace which depended on specific behaviours of the amdgpu kernel
driver, or breaking the expectations of generic userspace such as
Weston/Mutter/etc.

One good way to make sure you don't get into that position, is to have
core KMS code driving as much of the machinery as possible, with a
very clear separation of concerns between actual hardware programming,
versus things which may be visible to userspace. This I think is
DanielV's point expressed at much greater length. ;)

I should be clear though that this isn't unique to AMD, nor a problem
of your creation. For example, I'm currently looking at a flip-timing
issue in Rockchip - a fairly small, recent, atomic-native, and

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Jani Nikula]

On Tue, 13 Dec 2016, "Cheng, Tony"  wrote:
> I am struggling with that these comminty contributions to DC would be.
>
> Us AMD developer has access to HW docs and designer and we are still 
> spending 50% of our time figuring out why our HW doesn't work right. I 
> can't image community doing much of this heavy lifting.

I can sympathize with that view, and certainly most of the heavy lifting
would come from you, same as with us and i915. However, when you put
together your hardware, an open source driver, and smart people, they
*will* scratch their itches, whether they're bugs you're not fixing or
features you're missing. Please don't underestimate and patronize them,
it's going to rub people the wrong way.

> Dave sent us series of patch to show how it would look like if someone 
> were to change DC.  These changes are more removing code that DRM 
> already has and deleting/clean up stuff.  I guess we can nak all changes 
> and "rewrite" our own version of clean up patch community want to see?

Please have a look at, say,

$ git shortlog -sne --since @{1year} -- drivers/gpu/drm/amd | grep -v amd\.com

Do you really want to actively discourage all of them from contributing?
I think this would be detrimental to not only your driver, but the whole
drm community. It feels like you'd like to have your code upstream, but
still retain ownership as if it was in your internal repo. You can't
have your cake and eat it too.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Bridgman, John]

>>If the Linux community contributes to DC, I guess those contributions
can generally be assumed to be GPLv2 licensed.  Yet a future version
of the macOS driver would incorporate those contributions in the same
binary as their closed source OS-specific portion.


My understanding of the "general rule" was that contributions are normally 
assumed to be made under the "local license", ie GPLv2 for kernel changes in 
general, but the appropriate lower-level license when made to a specific 
subsystem with a more permissive license (eg the X11 license aka MIT aka "GPL 
plus additional rights" license we use for almost all of the graphics 
subsystem. If DC is not X11 licensed today it should be (but I'm pretty sure it 
already is).


We need to keep the graphics subsystem permissively licensed in general to 
allow uptake by other free OS projects such as *BSD, not just closed source.


Either way, driver-level maintainers are going to have to make sure that 
contributions have clear licensing.


Thanks,

John


From: dri-devel <dri-devel-boun...@lists.freedesktop.org> on behalf of Lukas 
Wunner <lu...@wunner.de>
Sent: December 13, 2016 4:40 AM
To: Cheng, Tony
Cc: Grodzovsky, Andrey; dri-devel; amd-gfx mailing list; Deucher, Alexander
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 09:52:08PM -0500, Cheng, Tony wrote:
> With DC the display hardware programming, resource optimization, power
> management and interaction with rest of system will be fully validated
> across multiple OSs.

Do I understand DAL3.jpg correctly that the macOS driver builds on top
of DAL Core?  I'm asking because the graphics drivers shipping with
macOS as well as on Apple's EFI Firmware Volume are closed source.

If the Linux community contributes to DC, I guess those contributions
can generally be assumed to be GPLv2 licensed.  Yet a future version
of the macOS driver would incorporate those contributions in the same
binary as their closed source OS-specific portion.

I don't quite see how that would be legal but maybe I'm missing
something.

Presumably the situation with the Windows driver is the same.

I guess you could maintain a separate branch sans community contributions
which would serve as a basis for closed source drivers, but not sure if
that is feasible given your resource constraints.

Thanks,

Lukas
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Lukas Wunner]

On Tue, Dec 13, 2016 at 10:03:58AM -0500, Cheng, Tony wrote:
> On 12/13/2016 4:40 AM, Lukas Wunner wrote:
> > If the Linux community contributes to DC, I guess those contributions
> > can generally be assumed to be GPLv2 licensed.  Yet a future version
> > of the macOS driver would incorporate those contributions in the same
> > binary as their closed source OS-specific portion.
> 
> I am struggling with that these comminty contributions to DC would be.
> 
> Us AMD developer has access to HW docs and designer and we are still
> spending 50% of our time figuring out why our HW doesn't work right.
> I can't image community doing much of this heavy lifting.

True, but past experience with radeon/amdgpu is that the community has
use cases that AMD developers don't specifically cater to, e.g. due to
lack of the required hardware or resource constraints.

E.g. Mario Kleiner has contributed lots of patches for proper vsync
handling which are needed for his neuroscience software.  I've
contributed DDC switching support for MacBook Pros to radeon.
Your driver becomes more useful, you get more customers, everyone wins.


> > Do I understand DAL3.jpg correctly that the macOS driver builds on top
> > of DAL Core?  I'm asking because the graphics drivers shipping with
> > macOS as well as on Apple's EFI Firmware Volume are closed source.
> 
> macOS currently ship with their own driver.  I can't really comment on what
> macOS do without getting into trouble.

The Intel Israel folks working on Thunderbolt are similarly between
the rock that is the community's expectation of openness and the hard
place that is Apple's secrecy.  So I sympathize with your situation,
kudos for trying to do the right thing.


> I guess we can nak all changes and "rewrite" our
> own version of clean up patch community want to see?

I don't think that would be workable honestly.

One way out of this conundrum might be to use a permissive license such
as BSD for DC.  Then whenever you merge a community patch, in addition
to informing the contributor thereof, send them a boilerplate one-liner
that community contributions are assumed to be under the same license
and if the contributor disagrees they should send a short notice to
have their contribution removed.

But IANAL.

Best regards,

Lukas
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

Only DM that’s open source is amdgpu_dm.the rest will remain closed 
source.I remember we had discussion around legal issues with our grand 
plan of unifying everything, and I remember maybe it was John who 
assured us that it's okay.John can you chime in how it would work with 
GPLv2 licsense?



On 12/13/2016 4:40 AM, Lukas Wunner wrote:

On Mon, Dec 12, 2016 at 09:52:08PM -0500, Cheng, Tony wrote:

With DC the display hardware programming, resource optimization, power
management and interaction with rest of system will be fully validated
across multiple OSs.

Do I understand DAL3.jpg correctly that the macOS driver builds on top
of DAL Core?  I'm asking because the graphics drivers shipping with
macOS as well as on Apple's EFI Firmware Volume are closed source.
macOS currently ship with their own driver.  I can't really comment on 
what macOS do without getting into trouble.

If the Linux community contributes to DC, I guess those contributions
can generally be assumed to be GPLv2 licensed.  Yet a future version
of the macOS driver would incorporate those contributions in the same
binary as their closed source OS-specific portion.

I am struggling with that these comminty contributions to DC would be.

Us AMD developer has access to HW docs and designer and we are still 
spending 50% of our time figuring out why our HW doesn't work right. I 
can't image community doing much of this heavy lifting.


I don't quite see how that would be legal but maybe I'm missing
something.

Presumably the situation with the Windows driver is the same.

I guess you could maintain a separate branch sans community contributions
which would serve as a basis for closed source drivers, but not sure if
that is feasible given your resource constraints.
Dave sent us series of patch to show how it would look like if someone 
were to change DC.  These changes are more removing code that DRM 
already has and deleting/clean up stuff.  I guess we can nak all changes 
and "rewrite" our own version of clean up patch community want to see?

Thanks,

Lukas


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Rob Clark]

On Mon, Dec 12, 2016 at 11:10 PM, Cheng, Tony  wrote:
> We need to treat most of resource that don't map well as global. One example
> is pixel pll.  We have 6 display pipes but only 2 or 3 plls in CI/VI, as a
> result we are limited in number of HDMI or DVI we can drive at the same
> time.  Also the pixel pll can be used to drive DP as well, so there is
> another layer of HW specific but we can't really contain it in crtc or
> encoder by itself.  Doing this resource allocation require knowlege of the
> whole system, and knowning which pixel pll is already used, and what can we
> support with remaining pll.
>
> Another ask is lets say we are driving 2 displays, we would always want
> instance 0 and instance 1 of scaler, timing generator etc getting used.  We
> want to avoid possiblity of due to different user mode commit sequence we
> end up with driving the 2 display with 0 and 2nd instance of HW.  Not only
> this configuration isn't really validated in the lab, we will be less
> effective in power gating as instance 0 and 1 are one the same tile.
> instead of having 2/3 of processing pipeline silicon power gated we can only
> power gate 1/3. And if we power gate wrong the you will have 1 of the 2
> display not lighting up.

Note that as of 4.10, drm/msm/mdp5 is dynamically assigning hwpipes to
planes tracked as part of the driver's global atomic state.  (And for
future hw we will need to dynamically assign layermixers to crtc's).
I'm also using global state for allocating SMP (basically fifo)
blocks.  And drm/i915 is also using global atomic state for shared
resources.

Dynamic assignment of hw resources to kms objects is not a problem,
and the locking model in atomic allows for this.  (I introduced one
new global modeset_lock to protect the global state, so only multiple
parallel updates which both touch shared state will serialize)

BR,
-R
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Tue, Dec 13, 2016 at 12:22:59PM +, Daniel Stone wrote:
> Hi Harry,
> I've been loathe to jump in here, not least because both cop roles
> seem to be taken, but ...
> 
> On 13 December 2016 at 01:49, Harry Wentland  wrote:
> > On 2016-12-11 09:57 PM, Dave Airlie wrote:
> >> On 8 December 2016 at 12:02, Harry Wentland  wrote:
> >> Sharing code is a laudable goal and I appreciate the resourcing
> >> constraints that led us to the point at which we find ourselves, but
> >> the way forward involves finding resources to upstream this code,
> >> dedicated people (even one person) who can spend time on a day by day
> >> basis talking to people in the open and working upstream, improving
> >> other pieces of the drm as they go, reading atomic patches and
> >> reviewing them, and can incrementally build the DC experience on top
> >> of the Linux kernel infrastructure. Then having the corresponding
> >> changes in the DC codebase happen internally to correspond to how the
> >> kernel code ends up looking. Lots of this code overlaps with stuff the
> >> drm already does, lots of is stuff the drm should be doing, so patches
> >> to the drm should be sent instead.
> >
> > Personally I'm with you on this and hope to get us there. I'm learning...
> > we're learning. I agree that changes on atomic, removing abstractions, etc.
> > should happen on dri-devel.
> >
> > When it comes to brand-new technologies (MST, Freesync), though, we're often
> > the first which means that we're spending a considerable amount of time to
> > get things right, working with HW teams, receiver vendors and other partners
> > internal and external to AMD. By the time we do get it right it's time to
> > hit the market. This gives us fairly little leeway to work with the
> > community on patches that won't land in distros for another half a year.
> > We're definitely hoping to improve some of this but it's not easy and in
> > some case impossible ahead of time (though definitely possibly after initial
> > release).
> 
> Speaking with my Wayland hat on, I think these need to be very
> carefully considered. Both MST and FreeSync have _significant_ UABI
> implications, which may not be immediately obvious when working with a
> single implementation. Having them working and validated with a
> vertical stack of amdgpu-DC/KMS + xf86-video-amdgpu +
> Mesa-amdgpu/AMDGPU-Pro is one thing, but looking outside the X11 world
> we now have Weston, Mutter and KWin all directly driving KMS, plus
> whatever Mir/Unity ends up doing (presumably the same), and that's
> just on the desktop. Beyond the desktop, there's also CrOS/Freon and
> Android/HWC. For better or worse, outside of Xorg and HWC, we no
> longer have a vendor-provided userspace component driving KMS.
> 
> It was also easy to get away with loose semantics before with X11
> imposing little to no structure on rendering, but we now have the twin
> requirements of an atomic and timing-precise ABI - see Mario Kleiner's
> unending quest for accuracy - and also a vendor-independent ABI. So a
> good part of the (not insignificant) pain incurred in the atomic
> transition for drivers, was in fact making those drivers conform to
> the expectations of the KMS UABI contract, which just happened to not
> have been tripped over previously.
> 
> Speaking with my Collabora hat on now: we did do a substantial amount
> of demidlayering on the Exynos driver, including an atomic conversion,
> on Google's behalf. The original Exynos driver happened to work with
> the Tizen stack, but ChromeOS exposed a huge amount of subtle
> behaviour differences between that and other drivers when using Freon.
> We'd also hit the same issues when attempting to use Weston on Exynos
> in embedded devices for OEMs we worked with, so took on the project to
> remove the midlayer and have as much as possible driven from generic
> code.
> 
> How the hardware is programmed is of course ultimately up to you, and
> in this regard AMD will be very different from Intel is very different
> from Nouveau is very different from Rockchip. But especially for new
> features like FreeSync, I think we need to be very conscious of
> walking the line between getting those features in early, and setting
> unworkable UABI in stone. It would be unfortunate if later on down the
> line, you had to choose between breaking older xf86-video-amdgpu
> userspace which depended on specific behaviours of the amdgpu kernel
> driver, or breaking the expectations of generic userspace such as
> Weston/Mutter/etc.
> 
> One good way to make sure you don't get into that position, is to have
> core KMS code driving as much of the machinery as possible, with a
> very clear separation of concerns between actual hardware programming,
> versus things which may be visible to userspace. This I think is
> DanielV's point expressed at much greater length. ;)
> 
> I should be clear though that this isn't unique to AMD, nor a problem
> 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Stone]

Hi Harry,
I've been loathe to jump in here, not least because both cop roles
seem to be taken, but ...

On 13 December 2016 at 01:49, Harry Wentland  wrote:
> On 2016-12-11 09:57 PM, Dave Airlie wrote:
>> On 8 December 2016 at 12:02, Harry Wentland  wrote:
>> Sharing code is a laudable goal and I appreciate the resourcing
>> constraints that led us to the point at which we find ourselves, but
>> the way forward involves finding resources to upstream this code,
>> dedicated people (even one person) who can spend time on a day by day
>> basis talking to people in the open and working upstream, improving
>> other pieces of the drm as they go, reading atomic patches and
>> reviewing them, and can incrementally build the DC experience on top
>> of the Linux kernel infrastructure. Then having the corresponding
>> changes in the DC codebase happen internally to correspond to how the
>> kernel code ends up looking. Lots of this code overlaps with stuff the
>> drm already does, lots of is stuff the drm should be doing, so patches
>> to the drm should be sent instead.
>
> Personally I'm with you on this and hope to get us there. I'm learning...
> we're learning. I agree that changes on atomic, removing abstractions, etc.
> should happen on dri-devel.
>
> When it comes to brand-new technologies (MST, Freesync), though, we're often
> the first which means that we're spending a considerable amount of time to
> get things right, working with HW teams, receiver vendors and other partners
> internal and external to AMD. By the time we do get it right it's time to
> hit the market. This gives us fairly little leeway to work with the
> community on patches that won't land in distros for another half a year.
> We're definitely hoping to improve some of this but it's not easy and in
> some case impossible ahead of time (though definitely possibly after initial
> release).

Speaking with my Wayland hat on, I think these need to be very
carefully considered. Both MST and FreeSync have _significant_ UABI
implications, which may not be immediately obvious when working with a
single implementation. Having them working and validated with a
vertical stack of amdgpu-DC/KMS + xf86-video-amdgpu +
Mesa-amdgpu/AMDGPU-Pro is one thing, but looking outside the X11 world
we now have Weston, Mutter and KWin all directly driving KMS, plus
whatever Mir/Unity ends up doing (presumably the same), and that's
just on the desktop. Beyond the desktop, there's also CrOS/Freon and
Android/HWC. For better or worse, outside of Xorg and HWC, we no
longer have a vendor-provided userspace component driving KMS.

It was also easy to get away with loose semantics before with X11
imposing little to no structure on rendering, but we now have the twin
requirements of an atomic and timing-precise ABI - see Mario Kleiner's
unending quest for accuracy - and also a vendor-independent ABI. So a
good part of the (not insignificant) pain incurred in the atomic
transition for drivers, was in fact making those drivers conform to
the expectations of the KMS UABI contract, which just happened to not
have been tripped over previously.

Speaking with my Collabora hat on now: we did do a substantial amount
of demidlayering on the Exynos driver, including an atomic conversion,
on Google's behalf. The original Exynos driver happened to work with
the Tizen stack, but ChromeOS exposed a huge amount of subtle
behaviour differences between that and other drivers when using Freon.
We'd also hit the same issues when attempting to use Weston on Exynos
in embedded devices for OEMs we worked with, so took on the project to
remove the midlayer and have as much as possible driven from generic
code.

How the hardware is programmed is of course ultimately up to you, and
in this regard AMD will be very different from Intel is very different
from Nouveau is very different from Rockchip. But especially for new
features like FreeSync, I think we need to be very conscious of
walking the line between getting those features in early, and setting
unworkable UABI in stone. It would be unfortunate if later on down the
line, you had to choose between breaking older xf86-video-amdgpu
userspace which depended on specific behaviours of the amdgpu kernel
driver, or breaking the expectations of generic userspace such as
Weston/Mutter/etc.

One good way to make sure you don't get into that position, is to have
core KMS code driving as much of the machinery as possible, with a
very clear separation of concerns between actual hardware programming,
versus things which may be visible to userspace. This I think is
DanielV's point expressed at much greater length. ;)

I should be clear though that this isn't unique to AMD, nor a problem
of your creation. For example, I'm currently looking at a flip-timing
issue in Rockchip - a fairly small, recent, atomic-native, and
generally exemplary driver - which I'm pretty sure is going to be
resolved by deleting more driver 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

On 12/13/2016 2:30 AM, Dave Airlie wrote:

(hit send too early)

We would love to upstream DC for all supported asic!  We made enough change
to make Sea Island work but it's really not validate to the extend we
validate Polaris on linux and no where close to what we do for 2017 ASICs.
With DC the display hardware programming, resource optimization, power
management and interaction with rest of system will be fully validated
across multiple OSs.  Therefore we have high confidence that the quality is
going to better than what we have upstreammed today.

I don't have a baseline to say if DC is in good enough quality for older
generation compare to upstream.  For example we don't have HW generate
bandwidth_calc for DCE 8/10 (Sea/Vocanic island family) but our code is
structured in a way that we assume bandwidth_calc is there.  None of us feel
like go untangle the formulas in windows driver at this point to create our
own version of bandwidth_calc.  It sort of work with HW default values but
some mode / config is likely to underflows.  If community is okay with
uncertain quality, sure we would love to upstream everything to reduce our
maintaince overhead.  You do get audio with DC on DCE8 though.

If we get any of this upstream, we should get all of the hw supported with it.

If it regresses we just need someone to debug why.

great will do.



Maybe let me share what we are doing and see if we can come up with
something to make DC work for both upstream and our internal need.  We are
sharing code not just on Linux and we will do our best to make our code
upstream friendly.  Last year we focussed on having enough code to prove
that our DAL rewrite works and get more people contributing to it.  We rush
a bit as a result we had a few legacy component we port from Windows driver
and we know it's bloat that needed to go.

We designed DC so HW can contribute bandwidth_calc magic and psuedo code to
program the HW blocks.  The HW blocks on the bottom of DC.JPG in models our
HW blocks and the programming sequence are provided by HW engineers.  If a
piece of HW need a bit toggled 7 times during power up I rather have HW
engineer put that in their psedo code rather than me trying to find that
sequence in some document.  Afterall they did simulate the HW with the
toggle sequence.  I guess these are back-end code Daniel talked about.  Can
we agree that DRM core is not interested in how things are done in that
layer and we can upstream these as it?

The next is dce_hwseq.c to program the HW blocks in correct sequence.  Some
HW block can be programmed in any sequence, but some requires strict
sequence to be followed.  For example Display CLK and PHY CLK need to be up
before we enable timing generator.  I would like these sequence to remain in
DC as it's really not DRM's business to know how to program the HW.  In a
way you can consider hwseq as a helper to commit state to HW.

Above hwseq is the dce*_resource.c.  It's job is to come up with the HW
state required to realize given config.  For example we would use the exact
same HW resources with same optimization setting to drive any same given
config.  If 4 x 4k@60 is supported with resource setting A on HW diagnositc
suite during bring up setting B on Linux then we have a problem.  It know
which HW block work with which block and their capability and limitations.
I hope you are not asking this stuff to move up to core because in reality
we should probably hide this in some FW, as HW expose the register to config
them differently that doesn't mean all combination of HW usage is validated.
To me resource is more of a helper to put together functional pipeline and
does not make any decision that any OS might be interested in.

These yellow boxes in DC.JPG are really specific to each generation of HW
and changes frequently.  These are things that HW has consider hiding it in
FW before.  Can we agree on those code (under /dc/dce*) can stay?

I think most of these things are fine to be part of the solution we end up at,
but I can't say for certain they won't require interface changes. I think the
most useful code is probably the stuff in the dce subdirectories.
okay as long as we can agree on this piece stay I am sure we can make it 
work.



Is this about demonstration how basic functionality work and add more
features with series of patches to make review eaiser?  If so I don't think
we are staff to do this kind of rewrite.  For example it make no sense to
hooking up bandwidth_calc to calculate HW magic if we don't have mem_input
to program the memory settings.  We need portion of hw_seq to ensure these
blocks are programming in correct sequence.  We will need to feed
bandwidth_calc it's required inputs, which is basically the whole system
state tracked in validate_context today, which means we basically need big
bulk of resource.c.  This effort might have benefit in reviewing the code,
but we will end up with pretty much similar if not the same as what we
already have.

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Mon, Dec 12, 2016 at 09:05:15PM -0500, Harry Wentland wrote:
> 
> On 2016-12-12 02:22 AM, Daniel Vetter wrote:
> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > Current version of DC:
> > > 
> > >  * 
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > 
> > > Once Alex pulls in the latest patches:
> > > 
> > >  * 
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > 
> > One more: That 4.7 here is going to be unbelievable amounts of pain for
> > you. Yes it's a totally sensible idea to just freeze your baseline kernel
> > because then linux looks a lot more like Windows where the driver abi is
> > frozen. But it makes following upstream entirely impossible, because
> > rebasing is always a pain and hence postponed. Which means you can't just
> > use the latest stuff in upstream drm, which means collaboration with
> > others and sharing bugfixes in core is a lot more pain, which then means
> > you do more than necessary in your own code and results in HALs like DAL,
> > perpetuating the entire mess.
> > 
> > So I think you don't just need to demidlayer DAL/DC, you also need to
> > demidlayer your development process. In our experience here at Intel that
> > needs continuous integration testing (in drm-tip), because even 1 month of
> > not resyncing with drm-next is sometimes way too long. See e.g. the
> > controlD regression we just had. And DAL is stuck on a 1 year old kernel,
> > so pretty much only of historical significance and otherwise dead code.
> > 
> > And then for any stuff which isn't upstream yet (like your internal
> > enabling, or DAL here, or our own internal enabling) you need continuous
> > rebasing When we started doing this years ago it was still
> > manually, but we still rebased like every few days to keep the pain down
> > and adjust continuously to upstream evolution. But then going to a
> > continous rebase bot that sends you mail when something goes wrong was
> > again a massive improvement.
> > 
> 
> I think we've seen that pain already but haven't quite realized how much of
> it is due to a mismatch in kernel trees. We're trying to move onto a tree
> following drm-next much more closely. I'd love to help automate some of that
> (time permitting). Would the drm-misc scripts be of any use with that? I
> only had a very cursory glance at those.

I've offered to Alex that we could include the amd trees (only stuff ready
for pull request) into drm-tip for continuous integration testing at
least. Would mean that Alex needs to use dim when updating those branches,
and you CI needs to test drm-tip (and do that everytime it changes, i.e.
really continuously).

For continues rebasing there's no ready-made thing public, but I highly
recommend you use one of the patch pile tools. In intel we have a glue of
quilt + tracking quilt state with git, implemented in the qf script in
maintainer-tools. That one has a lot more sharp edges than dim, but it
gets the job done. And the combination of git track + raw patch file for
seding is very powerful for rebasing.

Long term I'm hopefully that git series will become the new shiny, since
Josh Tripplet really understands the use-cases of having long-term
rebasing trees which are collaboratively maintainer. It's a lot nicer than
qf, but can't yet do everything we need (and likely what you'll need to be
able to rebase DC without going crazy).

> > I guess in the end Conway's law that your software architecture
> > necessarily reflects how you organize your teams applies again. Fix your
> > process and it'll become glaringly obvious to everyone involved that
> > DC-the-design as-is is entirely unworkeable and how it needs to be fixed.
> > 
> > From my own experience over the past few years: Doing that is a fun
> > journey ;-)
> > 
> 
> Absolutely. We're only at the start of this but have learned a lot from the
> community (maybe others in the DC team disagree with me somewhat).
> 
> Not sure if I fully agree that this means that DC-the-design-as-is will
> become apparent as unworkable... There are definitely pieces to be cleaned
> here and lessons learned from the DRM community but on the other hand we
> feel there are some good reasons behind our approach that we'd like to share
> with the community (some of which I'm learning myself).

Tony asking what the difference between a midlayer and a helper library is
is imo a good indicator that there's still learning to do in the team ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Mon, Dec 12, 2016 at 11:10:30PM -0500, Cheng, Tony wrote:
> Thanks for the write up for the guide.  We can definitely re-do atomic
> according to guideline provided as I am not satified with how our code look
> today.  To me it seems more like we need to shuffle stuff around and rename
> a few things than rewrite much of anything.
> 
> I hope to get an answer on the reply to Dave's question regarding to if
> there is anything else.  If we can keep most of the stuff under /dc as the
> "back end" helper and do most of the change under /amdgpu_dm then it isn't
> that difficult as we don't need to go deal with the fall out on other
> platforms.  Again it's not just windows.  We are fully aware that it's hard
> to find the common abstraction between all different OS so we try our best
> to have DC behave more like a helper than abstraction layer anyways.  In our
> design states and policies are domain of Display Managers (DM) and because
> of linux we also say anything DRM can do that's also domain of DM.  We don't
> put anything in DC that we don't feel comfortable if HW decide to hide it in
> FW.
> 
> 
> On 12/12/2016 9:33 PM, Harry Wentland wrote:
> > On 2016-12-11 03:28 PM, Daniel Vetter wrote:
> > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > > We propose to use the Display Core (DC) driver for display support on
> > > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc).
> > > > In order to
> > > > avoid a flag day the plan is to only support uGPU initially and
> > > > transition
> > > > to older ASICs gradually.
> > > 
> > > Bridgeman brought it up a few times that this here was the question
> > > - it's
> > > kinda missing a question mark, hard to figure this out ;-). I'd say for
> > 
> > My bad for the missing question mark (imprecise phrasing). On the other
> > hand letting this blow over a bit helped get us on the map a bit more
> > and allows us to argue the challenges (and benefits) of open source. :)
> > 
> > > upstream it doesn't really matter, but imo having both atomic and
> > > non-atomic paths in one driver is one world of hurt and I strongly
> > > recommend against it, at least if feasible. All drivers that switched
> > > switched in one go, the only exception was i915 (it took much longer
> > > than
> > > we ever feared, causing lots of pain) and nouveau (which only converted
> > > nv50+, but pre/post-nv50 have always been two almost completely separate
> > > worlds anyway).
> > > 
> > 
> trust me we would like to upstream everything.  Just we didn't invest enough
> in DC code in the previous generation so the quality might not be there.
> 
> > You mention the two probably most complex DRM drivers didn't switch in a
> > single go...  I imagine amdgpu/DC falls into the same category.
> > 
> > I think one of the problems is making a sudden change with a fully
> > validated driver without breaking existing use cases and customers. We
> > really should've started DC development in public and probably would do
> > that if we had to start anew.
> > 
> > > > The DC component has received extensive testing within AMD for
> > > > DCE8, 10, and
> > > > 11 GPUs and is being prepared for uGPU. Support should be better than
> > > > amdgpu's current display support.
> > > > 
> > > >  * All of our QA effort is focused on DC
> > > >  * All of our CQE effort is focused on DC
> > > >  * All of our OEM preloads and custom engagements use DC
> > > >  * DC behavior mirrors what we do for other OSes
> > > > 
> > > > The new asic utilizes a completely re-designed atom interface,
> > > > so we cannot
> > > > easily leverage much of the existing atom-based code.
> > > > 
> > > > We've introduced DC to the community earlier in 2016 and
> > > > received a fair
> > > > amount of feedback. Some of what we've addressed so far are:
> > > > 
> > > >  * Self-contain ASIC specific code. We did a bunch of work to pull
> > > >common sequences into dc/dce and leave ASIC specific code in
> > > >separate folders.
> > > >  * Started to expose AUX and I2C through generic kernel/drm
> > > >functionality and are mostly using that. Some of that code is still
> > > >needlessly convoluted. This cleanup is in progress.
> > > >  * Integrated Dave and Jerome’s work on removing abstraction in bios
> > > >parser.
> > > >  * Retire adapter service and asic capability
> > > >  * Remove some abstraction in GPIO
> > > > 
> > > > Since a lot of our code is shared with pre- and post-silicon validation
> > > > suites changes need to be done gradually to prevent breakages
> > > > due to a major
> > > > flag day.  This, coupled with adding support for new asics and
> > > > lots of new
> > > > feature introductions means progress has not been as quick as we
> > > > would have
> > > > liked. We have made a lot of progress none the less.
> > > > 
> > > > The remaining concerns that were brought up during the last
> > > > review that we
> > > > are working on addressing:
> > > > 
> > > >  * 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Dave Airlie]

(hit send too early)
> We would love to upstream DC for all supported asic!  We made enough change
> to make Sea Island work but it's really not validate to the extend we
> validate Polaris on linux and no where close to what we do for 2017 ASICs.
> With DC the display hardware programming, resource optimization, power
> management and interaction with rest of system will be fully validated
> across multiple OSs.  Therefore we have high confidence that the quality is
> going to better than what we have upstreammed today.
>
> I don't have a baseline to say if DC is in good enough quality for older
> generation compare to upstream.  For example we don't have HW generate
> bandwidth_calc for DCE 8/10 (Sea/Vocanic island family) but our code is
> structured in a way that we assume bandwidth_calc is there.  None of us feel
> like go untangle the formulas in windows driver at this point to create our
> own version of bandwidth_calc.  It sort of work with HW default values but
> some mode / config is likely to underflows.  If community is okay with
> uncertain quality, sure we would love to upstream everything to reduce our
> maintaince overhead.  You do get audio with DC on DCE8 though.

If we get any of this upstream, we should get all of the hw supported with it.

If it regresses we just need someone to debug why.

> Maybe let me share what we are doing and see if we can come up with
> something to make DC work for both upstream and our internal need.  We are
> sharing code not just on Linux and we will do our best to make our code
> upstream friendly.  Last year we focussed on having enough code to prove
> that our DAL rewrite works and get more people contributing to it.  We rush
> a bit as a result we had a few legacy component we port from Windows driver
> and we know it's bloat that needed to go.
>
> We designed DC so HW can contribute bandwidth_calc magic and psuedo code to
> program the HW blocks.  The HW blocks on the bottom of DC.JPG in models our
> HW blocks and the programming sequence are provided by HW engineers.  If a
> piece of HW need a bit toggled 7 times during power up I rather have HW
> engineer put that in their psedo code rather than me trying to find that
> sequence in some document.  Afterall they did simulate the HW with the
> toggle sequence.  I guess these are back-end code Daniel talked about.  Can
> we agree that DRM core is not interested in how things are done in that
> layer and we can upstream these as it?
>
> The next is dce_hwseq.c to program the HW blocks in correct sequence.  Some
> HW block can be programmed in any sequence, but some requires strict
> sequence to be followed.  For example Display CLK and PHY CLK need to be up
> before we enable timing generator.  I would like these sequence to remain in
> DC as it's really not DRM's business to know how to program the HW.  In a
> way you can consider hwseq as a helper to commit state to HW.
>
> Above hwseq is the dce*_resource.c.  It's job is to come up with the HW
> state required to realize given config.  For example we would use the exact
> same HW resources with same optimization setting to drive any same given
> config.  If 4 x 4k@60 is supported with resource setting A on HW diagnositc
> suite during bring up setting B on Linux then we have a problem.  It know
> which HW block work with which block and their capability and limitations.
> I hope you are not asking this stuff to move up to core because in reality
> we should probably hide this in some FW, as HW expose the register to config
> them differently that doesn't mean all combination of HW usage is validated.
> To me resource is more of a helper to put together functional pipeline and
> does not make any decision that any OS might be interested in.
>
> These yellow boxes in DC.JPG are really specific to each generation of HW
> and changes frequently.  These are things that HW has consider hiding it in
> FW before.  Can we agree on those code (under /dc/dce*) can stay?

I think most of these things are fine to be part of the solution we end up at,
but I can't say for certain they won't require interface changes. I think the
most useful code is probably the stuff in the dce subdirectories.

>
> Is this about demonstration how basic functionality work and add more
> features with series of patches to make review eaiser?  If so I don't think
> we are staff to do this kind of rewrite.  For example it make no sense to
> hooking up bandwidth_calc to calculate HW magic if we don't have mem_input
> to program the memory settings.  We need portion of hw_seq to ensure these
> blocks are programming in correct sequence.  We will need to feed
> bandwidth_calc it's required inputs, which is basically the whole system
> state tracked in validate_context today, which means we basically need big
> bulk of resource.c.  This effort might have benefit in reviewing the code,
> but we will end up with pretty much similar if not the same as what we
> already have.

This is 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Dave Airlie]

> We would love to upstream DC for all supported asic!  We made enough change
> to make Sea Island work but it's really not validate to the extend we
> validate Polaris on linux and no where close to what we do for 2017 ASICs.
> With DC the display hardware programming, resource optimization, power
> management and interaction with rest of system will be fully validated
> across multiple OSs.  Therefore we have high confidence that the quality is
> going to better than what we have upstreammed today.
>
> I don't have a baseline to say if DC is in good enough quality for older
> generation compare to upstream.  For example we don't have HW generate
> bandwidth_calc for DCE 8/10 (Sea/Vocanic island family) but our code is
> structured in a way that we assume bandwidth_calc is there.  None of us feel
> like go untangle the formulas in windows driver at this point to create our
> own version of bandwidth_calc.  It sort of work with HW default values but
> some mode / config is likely to underflows.  If community is okay with
> uncertain quality, sure we would love to upstream everything to reduce our
> maintaince overhead.  You do get audio with DC on DCE8 though.

If we get any of this upstream, we should get all of the hw supported with it.

If it regresses we just need someone to debug why.

> Maybe let me share what we are doing and see if we can come up with
> something to make DC work for both upstream and our internal need.  We are
> sharing code not just on Linux and we will do our best to make our code
> upstream friendly.  Last year we focussed on having enough code to prove
> that our DAL rewrite works and get more people contributing to it.  We rush
> a bit as a result we had a few legacy component we port from Windows driver
> and we know it's bloat that needed to go.
>
> We designed DC so HW can contribute bandwidth_calc magic and psuedo code to
> program the HW blocks.  The HW blocks on the bottom of DC.JPG in models our
> HW blocks and the programming sequence are provided by HW engineers.  If a
> piece of HW need a bit toggled 7 times during power up I rather have HW
> engineer put that in their psedo code rather than me trying to find that
> sequence in some document.  Afterall they did simulate the HW with the
> toggle sequence.  I guess these are back-end code Daniel talked about.  Can
> we agree that DRM core is not interested in how things are done in that
> layer and we can upstream these as it?
>
> The next is dce_hwseq.c to program the HW blocks in correct sequence.  Some
> HW block can be programmed in any sequence, but some requires strict
> sequence to be followed.  For example Display CLK and PHY CLK need to be up
> before we enable timing generator.  I would like these sequence to remain in
> DC as it's really not DRM's business to know how to program the HW.  In a
> way you can consider hwseq as a helper to commit state to HW.
>
> Above hwseq is the dce*_resource.c.  It's job is to come up with the HW
> state required to realize given config.  For example we would use the exact
> same HW resources with same optimization setting to drive any same given
> config.  If 4 x 4k@60 is supported with resource setting A on HW diagnositc
> suite during bring up setting B on Linux then we have a problem.  It know
> which HW block work with which block and their capability and limitations.
> I hope you are not asking this stuff to move up to core because in reality
> we should probably hide this in some FW, as HW expose the register to config
> them differently that doesn't mean all combination of HW usage is validated.
> To me resource is more of a helper to put together functional pipeline and
> does not make any decision that any OS might be interested in.
>
> These yellow boxes in DC.JPG are really specific to each generation of HW
> and changes frequently.  These are things that HW has consider hiding it in
> FW before.  Can we agree on those code (under /dc/dce*) can stay?

I think most of these things are fine to be part of the solution we end up at,
but I can't say for certain they won't require interface changes. I think the
most useful code is probably the stuff in the dce subdirectories.

>
> Is this about demonstration how basic functionality work and add more
> features with series of patches to make review eaiser?  If so I don't think
> we are staff to do this kind of rewrite.  For example it make no sense to
> hooking up bandwidth_calc to calculate HW magic if we don't have mem_input
> to program the memory settings.  We need portion of hw_seq to ensure these
> blocks are programming in correct sequence.  We will need to feed
> bandwidth_calc it's required inputs, which is basically the whole system
> state tracked in validate_context today, which means we basically need big
> bulk of resource.c.  This effort might have benefit in reviewing the code,
> but we will end up with pretty much similar if not the same as what we
> already have.

This is something people always say, 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

On 2016-12-11 03:28 PM, Daniel Vetter wrote:

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:

We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
avoid a flag day the plan is to only support uGPU initially and transition
to older ASICs gradually.


Bridgeman brought it up a few times that this here was the question - it's
kinda missing a question mark, hard to figure this out ;-). I'd say for


My bad for the missing question mark (imprecise phrasing). On the other 
hand letting this blow over a bit helped get us on the map a bit more 
and allows us to argue the challenges (and benefits) of open source. :)



upstream it doesn't really matter, but imo having both atomic and
non-atomic paths in one driver is one world of hurt and I strongly
recommend against it, at least if feasible. All drivers that switched
switched in one go, the only exception was i915 (it took much longer than
we ever feared, causing lots of pain) and nouveau (which only converted
nv50+, but pre/post-nv50 have always been two almost completely separate
worlds anyway).



You mention the two probably most complex DRM drivers didn't switch in a 
single go...  I imagine amdgpu/DC falls into the same category.


I think one of the problems is making a sudden change with a fully 
validated driver without breaking existing use cases and customers. We 
really should've started DC development in public and probably would do 
that if we had to start anew.



The DC component has received extensive testing within AMD for DCE8, 10, and
11 GPUs and is being prepared for uGPU. Support should be better than
amdgpu's current display support.

 * All of our QA effort is focused on DC
 * All of our CQE effort is focused on DC
 * All of our OEM preloads and custom engagements use DC
 * DC behavior mirrors what we do for other OSes

The new asic utilizes a completely re-designed atom interface, so we cannot
easily leverage much of the existing atom-based code.

We've introduced DC to the community earlier in 2016 and received a fair
amount of feedback. Some of what we've addressed so far are:

 * Self-contain ASIC specific code. We did a bunch of work to pull
   common sequences into dc/dce and leave ASIC specific code in
   separate folders.
 * Started to expose AUX and I2C through generic kernel/drm
   functionality and are mostly using that. Some of that code is still
   needlessly convoluted. This cleanup is in progress.
 * Integrated Dave and Jerome’s work on removing abstraction in bios
   parser.
 * Retire adapter service and asic capability
 * Remove some abstraction in GPIO

Since a lot of our code is shared with pre- and post-silicon validation
suites changes need to be done gradually to prevent breakages due to a major
flag day.  This, coupled with adding support for new asics and lots of new
feature introductions means progress has not been as quick as we would have
liked. We have made a lot of progress none the less.

The remaining concerns that were brought up during the last review that we
are working on addressing:

 * Continue to cleanup and reduce the abstractions in DC where it
   makes sense.
 * Removing duplicate code in I2C and AUX as we transition to using the
   DRM core interfaces.  We can't fully transition until we've helped
   fill in the gaps in the drm core that we need for certain features.
 * Making sure Atomic API support is correct.  Some of the semantics of
   the Atomic API were not particularly clear when we started this,
   however, that is improving a lot as the core drm documentation
   improves.  Getting this code upstream and in the hands of more
   atomic users will further help us identify and rectify any gaps we
   have.


Ok so I guess Dave is typing some more general comments about
demidlayering, let me type some guidelines about atomic. Hopefully this
all materializes itself a bit better into improved upstream docs, but meh.



Excellent writeup. Let us know when/if you want our review for upstream 
docs.


We'll have to really take some time to go over our atomic 
implementation. A couple small comments below with regard to DC.



Step 0: Prep

So atomic is transactional, but it's not validate + rollback or commit,
but duplicate state, validate and then either throw away or commit.
There's a few big reasons for this: a) partial atomic updates - if you
duplicate it's much easier to check that you have all the right locks b)
kfree() is much easier to check for correctness than a rollback code and
c) atomic_check functions are much easier to audit for invalid changes to
persistent state.



There isn't really any rollback. I believe even in our other drivers 
we've abandoned the rollback approach years ago because it doesn't 
really work on modern HW. Any rollback cases you might find in DC should 
really only be for catastrophic errors (read: something went horribly 
wrong... read: 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

On 2016-12-12 02:22 AM, Daniel Vetter wrote:

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:

Current version of DC:

 * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Once Alex pulls in the latest patches:

 * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7


One more: That 4.7 here is going to be unbelievable amounts of pain for
you. Yes it's a totally sensible idea to just freeze your baseline kernel
because then linux looks a lot more like Windows where the driver abi is
frozen. But it makes following upstream entirely impossible, because
rebasing is always a pain and hence postponed. Which means you can't just
use the latest stuff in upstream drm, which means collaboration with
others and sharing bugfixes in core is a lot more pain, which then means
you do more than necessary in your own code and results in HALs like DAL,
perpetuating the entire mess.

So I think you don't just need to demidlayer DAL/DC, you also need to
demidlayer your development process. In our experience here at Intel that
needs continuous integration testing (in drm-tip), because even 1 month of
not resyncing with drm-next is sometimes way too long. See e.g. the
controlD regression we just had. And DAL is stuck on a 1 year old kernel,
so pretty much only of historical significance and otherwise dead code.

And then for any stuff which isn't upstream yet (like your internal
enabling, or DAL here, or our own internal enabling) you need continuous
rebasing When we started doing this years ago it was still
manually, but we still rebased like every few days to keep the pain down
and adjust continuously to upstream evolution. But then going to a
continous rebase bot that sends you mail when something goes wrong was
again a massive improvement.



I think we've seen that pain already but haven't quite realized how much 
of it is due to a mismatch in kernel trees. We're trying to move onto a 
tree following drm-next much more closely. I'd love to help automate 
some of that (time permitting). Would the drm-misc scripts be of any use 
with that? I only had a very cursory glance at those.



I guess in the end Conway's law that your software architecture
necessarily reflects how you organize your teams applies again. Fix your
process and it'll become glaringly obvious to everyone involved that
DC-the-design as-is is entirely unworkeable and how it needs to be fixed.

From my own experience over the past few years: Doing that is a fun
journey ;-)



Absolutely. We're only at the start of this but have learned a lot from 
the community (maybe others in the DC team disagree with me somewhat).


Not sure if I fully agree that this means that DC-the-design-as-is will 
become apparent as unworkable... There are definitely pieces to be 
cleaned here and lessons learned from the DRM community but on the other 
hand we feel there are some good reasons behind our approach that we'd 
like to share with the community (some of which I'm learning myself).


Harry


Cheers, Daniel


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [RFC] Using DC in amdgpu for upcoming GPU

[Deucher, Alexander]

> -Original Message-
> From: Luke A. Guest [mailto:lagu...@archeia.com]
> Sent: Monday, December 12, 2016 11:17 AM
> To: Deucher, Alexander; 'Daniel Vetter'; Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
> 
> On 12/12/16 15:28, Deucher, Alexander wrote:
> >> -Original Message-
> >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> Behalf
> >> Of Daniel Vetter
> >> Sent: Monday, December 12, 2016 4:27 AM
> >> To: Bridgman, John
> >> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-de...@lists.freedesktop.org;
> amd-
> >> g...@lists.freedesktop.org; Daniel Vetter; Deucher, Alexander; Wentland,
> >> Harry
> >> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
> >>
> >> On Mon, Dec 12, 2016 at 07:54:54AM +, Bridgman, John wrote:
> >>> Yep, good point. We have tended to stay a bit behind bleeding edge
> >> because our primary tasks so far have been:
> >>>
> >>> 1. Support enterprise distros (with old kernels) via the hybrid driver
> >>> (AMDGPU-PRO), where the closer to upstream we get the more of a
> gap
> >> we
> >>> have to paper over with KCL code
> >> Hm, I thought resonable enterprise distros roll their drm core forward to
> >> the very latest upstream fairly often, so it shouldn't be too bad? Fixing
> >> this completely requires that you upstream your pre-production hw
> support
> >> early enough that by the time it ships its the backport is already in a
> >> realeased enterprise distro upgrade. But then adding bugfixes on top
> >> should be doable.
> > The issue is we need DAL/DC for enterprise distros and OEM preloads and,
> for workstation customers, we need some additional patches that aren't
> upstream yet because they we don’t have an open source user for them yet.
> This gets much easier once we get OCL and VK open sourced.  As for new asic
> support, unfortunately, they do not often align well with enterprise distros 
> at
> least for dGPUs (APUs are usually easier since the cycles are longer, dGPUs
> cycles are very fast).  The other problem with dGPUs is that we often can't
> release support for new hw or feature too much earlier than launch due to
> the very competitive dGPU environment in gaming and workstation.
> >
> >
> Apologies for spamming, but I didn't send this to all.
> 
> What Daniel said is something I've said to you before, especially
> regarding libdrm. You keep mentioning these patches you need, but tbh,
> there's no reason why these patches cannot be in patchwork so people can
> use them. I've asked for this for months and the response was,
> "shouldn't be a problem, but I won't get to it this week," months later,
> still not there.

The kernel side is public.  The dkms packages have the full source tree.  As I 
said before, we plan to make this all public, but just haven't had the time (as 
this thread shows, we've got a lot of other higher priority things on our 
plate).  Even when we do, it doesn’t change the fact that the patches can't go 
upstream at the moment so it doesn't fix the situation Daniel was talking about 
anyway.  Distro's generally don't take code that is not upstream yet.  While we 
only validate the dkms packages on the enterprise distros, they should be 
adaptable to other kernels.

Alex

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Luke A. Guest]

On 12/12/16 15:28, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Daniel Vetter
>> Sent: Monday, December 12, 2016 4:27 AM
>> To: Bridgman, John
>> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-de...@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; Daniel Vetter; Deucher, Alexander; Wentland,
>> Harry
>> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
>>
>> On Mon, Dec 12, 2016 at 07:54:54AM +, Bridgman, John wrote:
>>> Yep, good point. We have tended to stay a bit behind bleeding edge
>> because our primary tasks so far have been:
>>>
>>> 1. Support enterprise distros (with old kernels) via the hybrid driver
>>> (AMDGPU-PRO), where the closer to upstream we get the more of a gap
>> we
>>> have to paper over with KCL code
>> Hm, I thought resonable enterprise distros roll their drm core forward to
>> the very latest upstream fairly often, so it shouldn't be too bad? Fixing
>> this completely requires that you upstream your pre-production hw support
>> early enough that by the time it ships its the backport is already in a
>> realeased enterprise distro upgrade. But then adding bugfixes on top
>> should be doable.
> The issue is we need DAL/DC for enterprise distros and OEM preloads and, for 
> workstation customers, we need some additional patches that aren't upstream 
> yet because they we don’t have an open source user for them yet.  This gets 
> much easier once we get OCL and VK open sourced.  As for new asic support, 
> unfortunately, they do not often align well with enterprise distros at least 
> for dGPUs (APUs are usually easier since the cycles are longer, dGPUs cycles 
> are very fast).  The other problem with dGPUs is that we often can't release 
> support for new hw or feature too much earlier than launch due to the very 
> competitive dGPU environment in gaming and workstation.
>
>
Apologies for spamming, but I didn't send this to all.

What Daniel said is something I've said to you before, especially
regarding libdrm. You keep mentioning these patches you need, but tbh,
there's no reason why these patches cannot be in patchwork so people can
use them. I've asked for this for months and the response was,
"shouldn't be a problem, but I won't get to it this week," months later,
still not there.

Please just get your stuff public so the people who aren't on enterprise
and ancient OSes can upgrade their systems. This would enable me to test
amdgpu-pro and latest Mesa/LLVM alongside each other for Gentoo without
having to replace a source built libdrm with your ancient one.

Luke.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Luke A. Guest]

On 12/12/16 15:28, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Daniel Vetter
>> Sent: Monday, December 12, 2016 4:27 AM
>> To: Bridgman, John
>> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-de...@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; Daniel Vetter; Deucher, Alexander; Wentland,
>> Harry
>> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
>>
>> On Mon, Dec 12, 2016 at 07:54:54AM +, Bridgman, John wrote:
>>> Yep, good point. We have tended to stay a bit behind bleeding edge
>> because our primary tasks so far have been:
>>>
>>> 1. Support enterprise distros (with old kernels) via the hybrid driver
>>> (AMDGPU-PRO), where the closer to upstream we get the more of a gap
>> we
>>> have to paper over with KCL code
>> Hm, I thought resonable enterprise distros roll their drm core forward to
>> the very latest upstream fairly often, so it shouldn't be too bad? Fixing
>> this completely requires that you upstream your pre-production hw support
>> early enough that by the time it ships its the backport is already in a
>> realeased enterprise distro upgrade. But then adding bugfixes on top
>> should be doable.
> The issue is we need DAL/DC for enterprise distros and OEM preloads and, for 
> workstation customers, we need some additional patches that aren't upstream 
> yet because they we don’t have an open source user for them yet.  This gets 
> much easier once we get OCL and VK open sourced.  As for new asic support, 
> unfortunately, they do not often align well with enterprise distros at least 
> for dGPUs (APUs are usually easier since the cycles are longer, dGPUs cycles 
> are very fast).  The other problem with dGPUs is that we often can't release 
> support for new hw or feature too much earlier than launch due to the very 
> competitive dGPU environment in gaming and workstation.
>

What Daniel said is something I've said to you before, especially
regarding libdrm. You keep mentioning these patches you need, but tbh,
there's no reason why these patches cannot be in patchwork so people can
use them. I've asked for this for months and the response was,
"shouldn't be a problem, but I won't get to it this week," months later,
still not there.

Please just get your stuff public so the people who aren't on enterprise
and ancient OSes can upgrade their systems. This would enable me to test
amdgpu-pro and latest Mesa/LLVM alongside each other for Gentoo without
having to replace a source built libdrm with your ancient one.

Luke.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> Current version of DC:
> 
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> 
> Once Alex pulls in the latest patches:
> 
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

One more: That 4.7 here is going to be unbelievable amounts of pain for
you. Yes it's a totally sensible idea to just freeze your baseline kernel
because then linux looks a lot more like Windows where the driver abi is
frozen. But it makes following upstream entirely impossible, because
rebasing is always a pain and hence postponed. Which means you can't just
use the latest stuff in upstream drm, which means collaboration with
others and sharing bugfixes in core is a lot more pain, which then means
you do more than necessary in your own code and results in HALs like DAL,
perpetuating the entire mess.

So I think you don't just need to demidlayer DAL/DC, you also need to
demidlayer your development process. In our experience here at Intel that
needs continuous integration testing (in drm-tip), because even 1 month of
not resyncing with drm-next is sometimes way too long. See e.g. the
controlD regression we just had. And DAL is stuck on a 1 year old kernel,
so pretty much only of historical significance and otherwise dead code.

And then for any stuff which isn't upstream yet (like your internal
enabling, or DAL here, or our own internal enabling) you need continuous
rebasing When we started doing this years ago it was still
manually, but we still rebased like every few days to keep the pain down
and adjust continuously to upstream evolution. But then going to a
continous rebase bot that sends you mail when something goes wrong was
again a massive improvement.

I guess in the end Conway's law that your software architecture
necessarily reflects how you organize your teams applies again. Fix your
process and it'll become glaringly obvious to everyone involved that
DC-the-design as-is is entirely unworkeable and how it needs to be fixed.

From my own experience over the past few years: Doing that is a fun
journey ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Bridgman, John]

Yep, good point. We have tended to stay a bit behind bleeding edge because our 
primary tasks so far have been:


1. Support enterprise distros (with old kernels) via the hybrid driver 
(AMDGPU-PRO), where the closer to upstream we get the more of a gap we have to 
paper over with KCL code


2. Push architecturally simple code (new GPU support) upstream, where being 
closer to upstream makes the up-streaming task simpler but not by that much


So 4.7 isn't as bad a compromise as it might seem.


That said, in the case of DAL/DC it's a different story as you say... 
architecturally complex code needing to be woven into a fast-moving subsystem 
of the kernel. So for DAL/DC anything other than upstream is going to be a big 
pain.


OK, need to think that through.


Thanks !


From: dri-devel <dri-devel-boun...@lists.freedesktop.org> on behalf of Daniel 
Vetter <dan...@ffwll.ch>
Sent: December 12, 2016 2:22 AM
To: Wentland, Harry
Cc: Grodzovsky, Andrey; amd-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org; Deucher, Alexander; Cheng, Tony
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> Current version of DC:
>
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>
> Once Alex pulls in the latest patches:
>
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

One more: That 4.7 here is going to be unbelievable amounts of pain for
you. Yes it's a totally sensible idea to just freeze your baseline kernel
because then linux looks a lot more like Windows where the driver abi is
frozen. But it makes following upstream entirely impossible, because
rebasing is always a pain and hence postponed. Which means you can't just
use the latest stuff in upstream drm, which means collaboration with
others and sharing bugfixes in core is a lot more pain, which then means
you do more than necessary in your own code and results in HALs like DAL,
perpetuating the entire mess.

So I think you don't just need to demidlayer DAL/DC, you also need to
demidlayer your development process. In our experience here at Intel that
needs continuous integration testing (in drm-tip), because even 1 month of
not resyncing with drm-next is sometimes way too long. See e.g. the
controlD regression we just had. And DAL is stuck on a 1 year old kernel,
so pretty much only of historical significance and otherwise dead code.

And then for any stuff which isn't upstream yet (like your internal
enabling, or DAL here, or our own internal enabling) you need continuous
rebasing When we started doing this years ago it was still
manually, but we still rebased like every few days to keep the pain down
and adjust continuously to upstream evolution. But then going to a
continous rebase bot that sends you mail when something goes wrong was
again a massive improvement.

I guess in the end Conway's law that your software architecture
necessarily reflects how you organize your teams applies again. Fix your
process and it'll become glaringly obvious to everyone involved that
DC-the-design as-is is entirely unworkeable and how it needs to be fixed.

>From my own experience over the past few years: Doing that is a fun
journey ;-)

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Bridgman, John]

Thanks Dave. Apologies in advance for top posting but I'm stuck on a mail 
client that makes a big mess when I try...


>If DC was ready for the next-gen GPU it would be ready for the current
>GPU, it's not the specific ASIC code that is the problem, it's the
>huge midlayer sitting in the middle.


We realize that (a) we are getting into the high-risk-of-breakage part of the 
rework and (b) no matter how much we change the code structure there's a good 
chance that a month after it goes upstream one of us is going to find that more 
structural changes are required.


I was kinda thinking that if we are doing high-risk activities (risk of subtle 
breakage not obvious regression, and/or risk of making structural changes that 
turn out to be a bad idea even though we all thought they were correct last 
week) there's an argument for doing it in code which only supports cards that 
people can't buy yet.


From: Dave Airlie <airl...@gmail.com>
Sent: December 11, 2016 9:57 PM
To: Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Bridgman, John; Deucher, Alexander; 
Lazare, Jordan; Cheng, Tony; Cyr, Aric; Grodzovsky, Andrey
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU

On 8 December 2016 at 12:02, Harry Wentland <harry.wentl...@amd.com> wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to older ASICs gradually.

[FAQ: from past few days]

1) Hey you replied to Daniel, you never addressed the points of the RFC!
I've read it being said that I hadn't addressed the RFC, and you know
I've realised I actually had, because the RFC is great but it
presupposes the codebase as designed can get upstream eventually, and
I don't think it can. The code is too littered with midlayering and
other problems, that actually addressing the individual points of the
RFC would be missing the main point I'm trying to make.

This code needs rewriting, not cleaning, not polishing, it needs to be
split into its constituent parts, and reintegrated in a form more
Linux process friendly.

I feel that if I reply to the individual points Harry has raised in
this RFC, that it means the code would then be suitable for merging,
which it still won't, and I don't want people wasting another 6
months.

If DC was ready for the next-gen GPU it would be ready for the current
GPU, it's not the specific ASIC code that is the problem, it's the
huge midlayer sitting in the middle.

2) We really need to share all of this code between OSes, why does
Linux not want it?

Sharing code is a laudable goal and I appreciate the resourcing
constraints that led us to the point at which we find ourselves, but
the way forward involves finding resources to upstream this code,
dedicated people (even one person) who can spend time on a day by day
basis talking to people in the open and working upstream, improving
other pieces of the drm as they go, reading atomic patches and
reviewing them, and can incrementally build the DC experience on top
of the Linux kernel infrastructure. Then having the corresponding
changes in the DC codebase happen internally to correspond to how the
kernel code ends up looking. Lots of this code overlaps with stuff the
drm already does, lots of is stuff the drm should be doing, so patches
to the drm should be sent instead.

3) Then how do we upstream it?
Resource(s) need(s) to start concentrating at splitting this thing up
and using portions of it in the upstream kernel. We don't land fully
formed code in the kernel if we can avoid it. Because you can't review
the ideas and structure as easy as when someone builds up code in
chunks and actually develops in the Linux kernel. This has always
produced better more maintainable code. Maybe the result will end up
improving the AMD codebase as well.

4) Why can't we put this in staging?
People have also mentioned staging, Daniel has called it a dead end,
I'd have considered staging for this code base, and I still might.
However staging has rules, and the main one is code in staging needs a
TODO list, and agreed criteria for exiting staging, I don't think we'd
be able to get an agreement on what the TODO list should contain and
how we'd ever get all things on it done. If this code ended up in
staging, it would most likely require someone dedicated to recreating
it in the mainline driver in an incremental fashion, and I don't see
that resource being available.

5) Why is a midlayer bad?
I'm not going to go into specifics on the DC midlayer, but we abhor
midlayers for a fair few reasons. The main reason I find causes the
most issues is locking. When you have breaks in code flow between
multiple layers, but having layers calling back into previous layers
it becomes near impossible to track who owns the locking and what the
current locking state is.

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie airl...@gmail.com> wrote:
> On 10 December 2016 at 05:59, Daniel Vetter  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 for review feedback.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Alex Deucher]

On Fri, Dec 9, 2016 at 3:30 PM, Dave Airlie  wrote:
>> I think this is part of the reason a lot of people get fed up with working 
>> upstream in Linux.  I can respect your technical points and if you kept it 
>> to that, I'd be fine with it and we could have a technical discussion 
>> starting there.  But attacking us or our corporate culture is not cool.  I 
>> think perhaps you have been in the RH silo for too long.  Our corporate 
>> culture is not like RH's.  Like it or not, we have historically been a 
>> windows centric company.  We have a few small Linux team that has been 
>> engaged with the community for a long time, but the rest of the company has 
>> not.  We are working to improve it, but we can only do so many things at one 
>> time.  GPU cycles are fast.  There's only so much time in the day; we'd like 
>> to make our code perfect, but we also want to get it out to customers while 
>> the hw is still relevant.  We are finally at a point where our AMD Linux 
>> drivers are almost feature complete compared to windows and we have support 
>> upstream well before hw launch and we get shit on for trying to do the right 
>> thing.  It doesn't exactly make us want to continue contributing.  That's 
>> the problem with Linux.  Unless you are part time hacker who is part of the 
>> "in" crowd can spend all of his days tinkering with making the code perfect, 
>> a vendor with massive resources who can just through more people at it, or a 
>> throw it over the wall and forget it vendor (hey, my code can just live in 
>> staging), there's no room for you.
>
> I don't think that's fair, AMD as a company has a number of
> experienced Linux kernel developers, who are well aware of the
> upstream kernel development process and views. I should not be put in
> a position where I have to say no, that is frankly the position you
> are in as a maintainer, you work for AMD but you answer to the kernel
> development process out here. AMD is travelling a well travelled road
> here, Intel/Daniel have lots of times I've had to deal with the same
> problems, eventually Intel learn that what Daniel says matters and
> people are a lot happier. I brought up the AMD culture because either
> one of two things have happened here, a) you've lost sight of what
> upstream kernel code looks like, or b) people in AMD aren't listening
> to you, and if its the latter case then it is a direct result of the
> AMD culture, and so far I'm not willing to believe it's the former
> (except maybe CGS - still on the wall whether that was a good idea or
> a floodgate warning).
>
> From what I understood this DAL code was a rewrite from scratch, with
> upstreamability as a possible goal, it isn't directly taken from
> Windows or fglrx. This goal was not achieved, why do I have to live
> with the result. AMD could have done better, they have so many people
> experienced in how this thing should go down.

I think I over-reated a bit with this email.  What I really wanted to
say was that this was an RFC, basically saying this is how far we've
come, this is what we still need to do, and here's what we'd like to
do.  This was not a request to merge now or an ultimatum.  I
understand the requirements of upstream, I just didn't expect such a
visceral response from that original email and it put me on the
defensive.  I take our driver quality seriously and the idea of having
arbitrary large patches applied to "clean up" our code without our say
or validation didn't sit well with me.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

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.

On Fri, Dec 9, 2016 at 6:26 PM, Cheng, Tony  wrote:
>> Merging this code as well as maintaining a trust relationship with
>> Linus, also maintains a trust relationship with the Linux graphics
>> community and other drm contributors. There have been countless
>> requests from various companies and contributors to merge unsavoury
>> things over the years and we've denied them. They've all had the same
>> reasons behind why they couldn't do what we want and why we were
>> wrong, but lots of people have shown up who do get what we are at and
>> have joined the community and contributed drivers that conform to the 
>> standards.
>> Turning around now and saying well AMD ignored our directions, so
>> we'll give them a free pass even though we've denied you all the same
>> thing over time.
>
> I'd like to say that I acknowledge the good and hard work maintainers are 
> doing.  You nor the community is wrong to say no. I understand where the no 
> comes from.  If somebody wants to throw 100k lines into DAL I would say no as 
> well.
>
>> If I'd given in and merged every vendor coded driver as-is we'd never
>> have progressed to having atomic modesetting, there would have been
>> too many vendor HALs and abstractions that would have blocked forward
>> progression. Merging one HAL or abstraction is going to cause  pain,
>> but setting a precedent to merge more would be just downright stupid
>> maintainership.
>
>> Here's the thing, we want AMD to join the graphics community not hang
>> out inside the company in silos. We need to enable FreeSync on Linux,
>> go ask the community how would be best to do it, don't shove it inside
>> the driver hidden in a special ioctl. Got some new HDMI features that
>> are secret, talk to other ppl in the same position and work out a plan
>> for moving forward. At the moment there is no engaging with the Linux
>> stack because you aren't really using it, as long as you hide behind
>> the abstraction there won't be much engagement, and neither side
>> benefits, so why should we merge the code if nobody benefits?
>
>
>> The platform problem/Windows mindset is scary and makes a lot of
>> decisions for you, open source doesn't have those restrictions, and I
>> don't accept drivers that try and push those development model
>> problems into our codebase.
>
> I would like to share how platform problem/Windows mindset look from our 
> side.  We are dealing with ever more complex hardware with the push to reduce 
> power while driving more pixels through.  It is the power reduction that is 
> causing us driver developers most of the pain.  Display is a high bandwidth 
> real time memory fetch sub system which is always on, even when the system is 
> idle.  When the system is idle, pretty much all of power consumption comes 
> from display.  Can we use existing DRM infrastructure?  Definitely yes, if we 
> talk about modes up to 300Mpix/s and leaving a lot of voltage and clock 
> margin on the table.  How hard is it to set up a timing while bypass most of 
> the pixel processing pipeline to light up a display?  How about adding all 
> the power optimization such as burst read to fill display cache and keep DRAM 
> in self-refresh as much as possible?  How about powering off some of the 
> cache or pixel processing pipeline if we are not using them?  We need to 
> manage and maximize valuable resources like cache (cache == silicon area == 
> $$) and clock (== power) and optimize memory request patterns at different 
> memory clock speeds, while DPM is going, in real time on the system.  This is 
> why there is so much code to program registers, track our states, and manages 
> resources, and it's getting more complex as HW would prefer SW program the 
> same value into 5 different registers in different sub blocks to save a few 
> cross tile wires on silicon and do complex calculations to find the magical 
> optimal settings (the hated bandwidth_cals.c).  There are a lot of registers 
> need to be programmed to correct values in the right situation if we enable 
> all these power/performance optimizations.
>
> It's really not a problem of windows mindset, rather is what is the bring up 
> platform when silicon is in the lab with HW designer support.  Today no 
> surprise we do that almost exclusively on windows.  Display team is working 
> hard to change that to have linux in the mix while we have the attention from 
> HW designers.  We have a recent effort to try to enable all power features on 
> Stoney (current gen low 

RE: [RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

> Merging this code as well as maintaining a trust relationship with 
> Linus, also maintains a trust relationship with the Linux graphics 
> community and other drm contributors. There have been countless 
> requests from various companies and contributors to merge unsavoury 
> things over the years and we've denied them. They've all had the same 
> reasons behind why they couldn't do what we want and why we were 
> wrong, but lots of people have shown up who do get what we are at and 
> have joined the community and contributed drivers that conform to the 
> standards.
> Turning around now and saying well AMD ignored our directions, so 
> we'll give them a free pass even though we've denied you all the same 
> thing over time.

I'd like to say that I acknowledge the good and hard work maintainers are 
doing.  You nor the community is wrong to say no. I understand where the no 
comes from.  If somebody wants to throw 100k lines into DAL I would say no as 
well.

> If I'd given in and merged every vendor coded driver as-is we'd never 
> have progressed to having atomic modesetting, there would have been  
> too many vendor HALs and abstractions that would have blocked forward 
> progression. Merging one HAL or abstraction is going to cause  pain, 
> but setting a precedent to merge more would be just downright stupid 
> maintainership.

> Here's the thing, we want AMD to join the graphics community not hang 
> out inside the company in silos. We need to enable FreeSync on Linux, 
> go ask the community how would be best to do it, don't shove it inside 
> the driver hidden in a special ioctl. Got some new HDMI features that 
> are secret, talk to other ppl in the same position and work out a plan 
> for moving forward. At the moment there is no engaging with the Linux 
> stack because you aren't really using it, as long as you hide behind 
> the abstraction there won't be much engagement, and neither side 
> benefits, so why should we merge the code if nobody benefits?


> The platform problem/Windows mindset is scary and makes a lot of 
> decisions for you, open source doesn't have those restrictions, and I 
> don't accept drivers that try and push those development model 
> problems into our codebase.

I would like to share how platform problem/Windows mindset look from our side.  
We are dealing with ever more complex hardware with the push to reduce power 
while driving more pixels through.  It is the power reduction that is causing 
us driver developers most of the pain.  Display is a high bandwidth real time 
memory fetch sub system which is always on, even when the system is idle.  When 
the system is idle, pretty much all of power consumption comes from display.  
Can we use existing DRM infrastructure?  Definitely yes, if we talk about modes 
up to 300Mpix/s and leaving a lot of voltage and clock margin on the table.  
How hard is it to set up a timing while bypass most of the pixel processing 
pipeline to light up a display?  How about adding all the power optimization 
such as burst read to fill display cache and keep DRAM in self-refresh as much 
as possible?  How about powering off some of the cache or pixel processing 
pipeline if we are not using them?  We need to manage and maximize valuable 
resources like cache (cache == silicon area == $$) and clock (== power) and 
optimize memory request patterns at different memory clock speeds, while DPM is 
going, in real time on the system.  This is why there is so much code to 
program registers, track our states, and manages resources, and it's getting 
more complex as HW would prefer SW program the same value into 5 different 
registers in different sub blocks to save a few cross tile wires on silicon and 
do complex calculations to find the magical optimal settings (the hated 
bandwidth_cals.c).  There are a lot of registers need to be programmed to 
correct values in the right situation if we enable all these power/performance 
optimizations.

It's really not a problem of windows mindset, rather is what is the bring up 
platform when silicon is in the lab with HW designer support.  Today no 
surprise we do that almost exclusively on windows.  Display team is working 
hard to change that to have linux in the mix while we have the attention from 
HW designers.  We have a recent effort to try to enable all power features on 
Stoney (current gen low power APU) to match idle power on windows after Stoney 
shipped.  Linux driver guys working hard on it for 4+ month and still having 
hard time getting over the hurdle without support from HW designers because 
designers are tied up with the next generation silicon currently in the lab and 
the rest of them already moved onto next next generation.  To me I would rather 
have everything built on top of DC, including HW diagnostic test suites.  Even 
if I have to build DC on top of DRM mode setting I would prefer that over 
trying to do another bring up without HW support.  After all as driver 
developer 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

Hi Alex,

I'll leave the other bits out, just replying to atomic/android comments.

On Fri, Dec 9, 2016 at 6:32 PM, Deucher, Alexander
 wrote:
> I understand forward progress on APIs, but frankly from my perspective, 
> atomic has been a disaster for stability of both atomic and pre-atomic code.  
> Every kernel cycle manages to break several drivers.  What happened to 
> figuring out how to do in right in a couple of drivers and then moving that 
> to the core.  We seem to have lost that in favor of starting in the core 
> first.  I feel like we constantly refactor the core to deal with that or that 
> quirk or requirement of someone's hardware and then deal with tons of 
> fallout.  Is all we care about android?  I constantly hear the argument, if 
> we don't do all of this android will do their own thing and then that will be 
> the end.  Right now we are all suffering and android barely even using this 
> yet.  If Linux will carry on without AMD contributing maybe Linux will carry 
> on ok without bending over backwards for android.  Are you basically telling 
> us that you'd rather we water down our driver and limit the features and 
> capabilities and stability we can support so that others can refactor our 
> code constantly for hazy goals to support some supposed glorious future that 
> never seems to come?  What about right now?  Maybe we could try and support 
> some features right now.  Maybe we'll finally see Linux on the desktop.

Before atomic landed we've had 3 proof-of-concept drivers. Before I've
added the the nonblocking helpers we've had about 5-10 drivers doing
it all wrong in different ways (and yes the rework highlighted that in
a few cases rather brutally). We know have about 20 atomic drivers
(and counting), and pretty much all the refactoring, helper
extractions and reworks _are_ motivated by a bunch of drivers
hand-rolling a given pattern. So I think we're doing things roughly
right, it's just a bit hard.

And no Android isn't everything we care about, we want atomic also for
CrOS (which is pretty much the only linux desktop thing shipping in
quantities), and we want it for the traditional linux desktop
(weston/wayland/mutter). And we want it for embedded/entertainment
systems. Atomic is pretty much the answer to "KMS is outdated and
doesn't match modern hw anymore". E.g. on i915 we want atomic (and
related work) to be able to support render compression.

And of course I'd like to invite everyone who wants something else
with DRM to also bring that in, e.g. over the past few months we've
merged the simple kms helpers for super-dumb displays to be able to be
better at the fbdev game than fbdev itself. Not something I care about
personally, but it's still great because more users and usecases.

And the same applies of course to AMD. But what I'm seeing (and you're
not the only one complaining, Michel has raised this on irc a few
times too) is that you're not in the driver seat, and AMD folks don't
really have any say in where DRM overall heads towards. As an outsider
looking in I think that's because AMD is largely absorbed with itself,
doesn't have people who can just do random things because they see the
long-term benefits, and is occopied absorbing new teams that don't yet
design and develop with an upstream first approach. Personally I'm not
really happy about that, because I'd like more of AMD's perspective in
infrastructure work. But I don't think that's because upstream and
maintainers reject your stuff, I'm trying as hard as possible to drag
you folks in all the time, and tons of people get stuff merged with
even smaller teams than you have.I think it's simply because core work
seems not to be a top priority (yet). I can't fix that.

You're other criticism is that all these changes break shit, and agree
there's been a bit much of that. But otoh if we can't change e.g. fb
refcounting anymore because it would break drivers, or try to
deprecate old interfaces to get rid of the plenty of rootholes in
there, then upstream is dead and why should we bother with having a
standardized, cross-vendor modeset interface. And I'm trying to fix
this mess, by emphasising CI, building up a cross-vendor validation
suite in igt, inviting folks to participate in drm-misc to make sure
core stuff is working for everyone and moves in the right direction.
And again lots of people pick up on that offer, and we have multiple
people and vendors now e.g. looking into igt and starting to
contribute. But again AMD is left out, and I don't think that can be
blamed on the community.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Dave Airlie]

> I think this is part of the reason a lot of people get fed up with working 
> upstream in Linux.  I can respect your technical points and if you kept it to 
> that, I'd be fine with it and we could have a technical discussion starting 
> there.  But attacking us or our corporate culture is not cool.  I think 
> perhaps you have been in the RH silo for too long.  Our corporate culture is 
> not like RH's.  Like it or not, we have historically been a windows centric 
> company.  We have a few small Linux team that has been engaged with the 
> community for a long time, but the rest of the company has not.  We are 
> working to improve it, but we can only do so many things at one time.  GPU 
> cycles are fast.  There's only so much time in the day; we'd like to make our 
> code perfect, but we also want to get it out to customers while the hw is 
> still relevant.  We are finally at a point where our AMD Linux drivers are 
> almost feature complete compared to windows and we have support upstream well 
> before hw launch and we get shit on for trying to do the right thing.  It 
> doesn't exactly make us want to continue contributing.  That's the problem 
> with Linux.  Unless you are part time hacker who is part of the "in" crowd 
> can spend all of his days tinkering with making the code perfect, a vendor 
> with massive resources who can just through more people at it, or a throw it 
> over the wall and forget it vendor (hey, my code can just live in staging), 
> there's no room for you.

I don't think that's fair, AMD as a company has a number of
experienced Linux kernel developers, who are well aware of the
upstream kernel development process and views. I should not be put in
a position where I have to say no, that is frankly the position you
are in as a maintainer, you work for AMD but you answer to the kernel
development process out here. AMD is travelling a well travelled road
here, Intel/Daniel have lots of times I've had to deal with the same
problems, eventually Intel learn that what Daniel says matters and
people are a lot happier. I brought up the AMD culture because either
one of two things have happened here, a) you've lost sight of what
upstream kernel code looks like, or b) people in AMD aren't listening
to you, and if its the latter case then it is a direct result of the
AMD culture, and so far I'm not willing to believe it's the former
(except maybe CGS - still on the wall whether that was a good idea or
a floodgate warning).

From what I understood this DAL code was a rewrite from scratch, with
upstreamability as a possible goal, it isn't directly taken from
Windows or fglrx. This goal was not achieved, why do I have to live
with the result. AMD could have done better, they have so many people
experienced in how this thing should go down.

> You love to tell the exynos story about how crappy the code was and then 
> after it was cleaned up how glorious it was. Except the vendor didn't do 
> that.  Another vendor paid another vendor to do it.  We don't happen to have 
> the resources to pay someone else to do that for us.  Moreover, doing so 
> would negate all of the advantages to bringing up the code along with the hw 
> team in the lab when the asics come back from the fab.  Additionally, the 
> original argument against the exynos code was that it was just thrown over 
> the wall and largely ignored by the vendor once it was upstream.  We've been 
> consistently involved in upstream (heck, I've been at AMD almost 10 years now 
> maintaining our drivers).  You talk about trust.  I think there's something 
> to cutting a trusted partner some slack as they work to further improve their 
> support vs. taking a hard line because you got burned once by a throw it over 
> the wall vendor who was not engaged.  Even if you want to take a hard line, 
> let's discuss it on technical merits, not mud-slinging.

Here's the thing, what happens if a vendor pays another vendor to
clean up DAL after I merge it, how do you handle it? Being part of the
upstream kernel isn't about hiding in the corner, if you want to gain
the benefits of upstream development you need to participate in
upstream development. If you want to do what AMD seems to be only in a
position to do, and have upstream development as an after thought then
you of course are going to run into lots of problems.

>
> I realize you care about code quality and style, but do you care about stable 
> functionality?  Would you really merge a bunch of huge cleanups that would 
> potentially break tons of stuff in subtle ways because coding style is that 
> important?  I'm done with that myself.  I've merged too many half-baked 
> cleanups and new features in the past and ended up spending way more time 
> fixing them than I would have otherwise for relatively little gain.  The hw 
> is just too complicated these days.  At some point people what support for 
> the hw they have and they want it to work.  If code trumps all, then why do 
> we have 

RE: [RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

> Merging this code as well as maintaining a trust relationship with 
> Linus, also maintains a trust relationship with the Linux graphics 
> community and other drm contributors. There have been countless 
> requests from various companies and contributors to merge unsavoury 
> things over the years and we've denied them. They've all had the same 
> reasons behind why they couldn't do what we want and why we were 
> wrong, but lots of people have shown up who do get what we are at and 
> have joined the community and contributed drivers that conform to the 
> standards.
> Turning around now and saying well AMD ignored our directions, so 
> we'll give them a free pass even though we've denied you all the same 
> thing over time.

I'd like to say that I acknowledge the good and hard work maintainers are 
doing.  You nor the community is wrong to say no. I understand where the no 
comes from.  If somebody wants to throw 100k lines into DAL I would say no as 
well.

> If I'd given in and merged every vendor coded driver as-is we'd never 
> have progressed to having atomic modesetting, there would have been 
> too many vendor HALs and abstractions that would have blocked forward 
> progression. Merging one HAL or abstraction is going to cause  pain, 
> but setting a precedent to merge more would be just downright stupid 
> maintainership.

> Here's the thing, we want AMD to join the graphics community not hang 
> out inside the company in silos. We need to enable FreeSync on Linux, 
> go ask the community how would be best to do it, don't shove it inside 
> the driver hidden in a special ioctl. Got some new HDMI features that 
> are secret, talk to other ppl in the same position and work out a plan 
> for moving forward. At the moment there is no engaging with the Linux 
> stack because you aren't really using it, as long as you hide behind 
> the abstraction there won't be much engagement, and neither side 
> benefits, so why should we merge the code if nobody benefits?


> The platform problem/Windows mindset is scary and makes a lot of 
> decisions for you, open source doesn't have those restrictions, and I 
> don't accept drivers that try and push those development model 
> problems into our codebase.

I would like to share how platform problem/Windows mindset look from our side.  
We are dealing with ever more complex hardware with the push to reduce power 
while driving more pixels through.  It is the power reduction that is causing 
us driver developers most of the pain.  Display is a high bandwidth real time 
memory fetch sub system which is always on, even when the system is idle.  When 
the system is idle, pretty much all of power consumption comes from display.  
Can we use existing DRM infrastructure?  Definitely yes, if we talk about modes 
up to 300Mpix/s and leaving a lot of voltage and clock margin on the table.  
How hard is it to set up a timing while bypass most of the pixel processing 
pipeline to light up a display?  How about adding all the power optimization 
such as burst read to fill display cache and keep DRAM in self-refresh as much 
as possible?  How about powering off some of the cache or pixel processing 
pipeline if we are not using them?  We need to manage and maximize valuable 
resources like cache (cache == silicon area == $$) and clock (== power) and 
optimize memory request patterns at different memory clock speeds, while DPM is 
going, in real time on the system.  This is why there is so much code to 
program registers, track our states, and manages resources, and it's getting 
more complex as HW would prefer SW program the same value into 5 different 
registers in different sub blocks to save a few cross tile wires on silicon and 
do complex calculations to find the magical optimal settings (the hated 
bandwidth_cals.c).  There are a lot of registers need to be programmed to 
correct values in the right situation if we enable all these power/performance 
optimizations.

It's really not a problem of windows mindset, rather is what is the bring up 
platform when silicon is in the lab with HW designer support.  Today no 
surprise we do that almost exclusively on windows.  Display team is working 
hard to change that to have linux in the mix while we have the attention from 
HW designers.  We have a recent effort to try to enable all power features on 
Stoney (current gen low power APU) to match idle power on windows after Stoney 
shipped.  Linux driver guys working hard on it for 4+ month and still having 
hard time getting over the hurdle without support from HW designers because 
designers are tied up with the next generation silicon currently in the lab and 
the rest of them already moved onto next next generation.  To me I would rather 
have everything built on top of DC, including HW diagnostic test suites.  Even 
if I have to build DC on top of DRM mode setting I would prefer that over 
trying to do another bring up without HW support.  After all as driver 
developer 

RE: [RFC] Using DC in amdgpu for upcoming GPU

[Deucher, Alexander]

> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Thursday, December 08, 2016 3:07 PM
> To: Daniel Vetter
> Cc: Wentland, Harry; dri-devel; Grodzovsky, Andrey; amd-gfx mailing list;
> Deucher, Alexander; Cheng, Tony
> Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
> 
> > I can't dig into details of DC, so this is not a 100% assessment, but if
> > you call a function called "validate" in atomic_commit, you're very, very
> > likely breaking atomic. _All_ validation must happen in ->atomic_check,
> > if that's not the case TEST_ONLY mode is broken. And atomic userspace is
> > relying on that working.
> >
> > The only thing that you're allowed to return from ->atomic_commit is
> > out-of-memory, hw-on-fire and similar unforeseen and catastrophic issues.
> > Kerneldoc expklains this.
> >
> > Now the reason I bring this up (and we've discussed it at length in
> > private) is that DC still suffers from a massive abstraction midlayer. A
> > lot of the back-end stuff (dp aux, i2c, abstractions for allocation,
> > timers, irq, ...) have been cleaned up, but the midlayer is still there.
> > And I understand why you have it, and why it's there - without some OS
> > abstraction your grand plan of a unified driver across everything doesn't
> > work out so well.
> >
> > But in a way the backend stuff isn't such a big deal. It's annoying since
> > lots of code, and bugfixes have to be duplicated and all that, but it's
> > fairly easy to fix case-by-case, and as long as AMD folks stick around
> > (which I fully expect) not a maintainance issue. It makes it harder for
> > others to contribute, but then since it's mostly the leaf it's generally
> > easy to just improve the part you want to change (as an outsider). And if
> > you want to improve shared code the only downside is that you can't also
> > improve amd, but that's not so much a problem for non-amd folks ;-)
> >
> > The problem otoh with the abstraction layer between drm core and the
> amd
> > driver is that you can't ignore if you want to refactor shared code. And
> > because it's an entire world of its own, it's much harder to understand
> > what the driver is doing (without reading it all). Some examples of what I
> > mean:
> >
> > - All other drm drivers subclass drm objects (by embedding them) into the
> >   corresponding hw part that most closely matches the drm object's
> >   semantics. That means even when you have 0 clue about how a given
> piece
> >   of hw works, you have a reasonable chance of understanding code. If it's
> >   all your own stuff you always have to keep in minde the special amd
> >   naming conventions. That gets old real fast if you trying to figure out
> >   what 20+ (or are we at 30 already?) drivers are doing.
> >
> > - This is even more true for atomic. Atomic has a pretty complicated
> >   check/commmit transactional model for updating display state. It's a
> >   standardized interface, and it's extensible, and we want generic
> >   userspace to be able to run on any driver. Fairly often we realize that
> >   semantics of existing or newly proposed properties and state isn't
> >   well-defined enough, and then we need to go all the drivers and
> >   figure out how to fix up the mess. DC has it's entirely separate state
> >   structures which again don't subclass the atomic core structures (afaik
> >   at least). Again the same problems apply that you can't find things, and
> >   that figuring out the exact semantics and spotting differences in
> >   behaviour is almost impossible.
> >
> > - The trouble isn't just in reading code and understanding it correctly,
> >   it's also in finding it. If you have your own completely different world
> >   then just finding the right code is hard - cscope and grep fail to work.
> >
> > - Another issue is that very often we unify semantics in drivers by adding
> >   some new helpers that at least dtrt for most of the drivers. If you have
> >   your own world then the impendance mismatch will make sure that amd
> >   drivers will have slightly different semantics, and I think that's not
> >   good for the ecosystem and kms - people want to run a lot more than just
> >   a boot splash with generic kms userspace, stuff like xf86-video-$vendor
> >   is going out of favour heavily.
> >
> > Note that all this isn't about amd walking away and leaving an
> > unmaintainable mess behind. Like I've said I don't think this is a big
> > risk. The trouble is that having your own world makes it harder for
> > ev

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Dave Airlie]

>
> No.
>

I'd also like to apologise for the formatting, gmail great for typing,
crap for editing.

So I've thought about it a bit more and Daniel mentioned something
useful I thought I should add.

Merging this code as well as maintaining a trust relationship with
Linus, also maintains a trust relationship with the Linux graphics
community and other drm contributors. There have been countless
requests from various companies and contributors to merge unsavoury
things over the years and we've denied them. They've all had the same
reasons behind why they couldn't do what we want and why we were
wrong, but lots of people have shown up who do get what we are at and
have joined the community and contributed drivers that conform to the
standards. Turning around now and saying well AMD ignored our
directions, so we'll give them a free pass even though we've denied
you all the same thing over time.

If I'd given in and merged every vendor coded driver as-is we'd never
have progressed to having atomic modesetting, there would have been
too many vendor HALs and abstractions that would have blocked forward
progression. Merging one HAL or abstraction is going to cause pain,
but setting a precedent to merge more would be just downright stupid
maintainership.

Here's the thing, we want AMD to join the graphics community not hang
out inside the company in silos. We need to enable FreeSync on Linux,
go ask the community how would be best to do it, don't shove it inside
the driver hidden in a special ioctl. Got some new HDMI features that
are secret, talk to other ppl in the same position and work out a plan
for moving forward. At the moment there is no engaging with the Linux
stack because you aren't really using it, as long as you hide behind
the abstraction there won't be much engagement, and neither side
benefits, so why should we merge the code if nobody benefits?

The platform problem/Windows mindset is scary and makes a lot of
decisions for you, open source doesn't have those restrictions, and I
don't accept drivers that try and push those development model
problems into our codebase.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Dave Airlie]

> I can't dig into details of DC, so this is not a 100% assessment, but if
> you call a function called "validate" in atomic_commit, you're very, very
> likely breaking atomic. _All_ validation must happen in ->atomic_check,
> if that's not the case TEST_ONLY mode is broken. And atomic userspace is
> relying on that working.
>
> The only thing that you're allowed to return from ->atomic_commit is
> out-of-memory, hw-on-fire and similar unforeseen and catastrophic issues.
> Kerneldoc expklains this.
>
> Now the reason I bring this up (and we've discussed it at length in
> private) is that DC still suffers from a massive abstraction midlayer. A
> lot of the back-end stuff (dp aux, i2c, abstractions for allocation,
> timers, irq, ...) have been cleaned up, but the midlayer is still there.
> And I understand why you have it, and why it's there - without some OS
> abstraction your grand plan of a unified driver across everything doesn't
> work out so well.
>
> But in a way the backend stuff isn't such a big deal. It's annoying since
> lots of code, and bugfixes have to be duplicated and all that, but it's
> fairly easy to fix case-by-case, and as long as AMD folks stick around
> (which I fully expect) not a maintainance issue. It makes it harder for
> others to contribute, but then since it's mostly the leaf it's generally
> easy to just improve the part you want to change (as an outsider). And if
> you want to improve shared code the only downside is that you can't also
> improve amd, but that's not so much a problem for non-amd folks ;-)
>
> The problem otoh with the abstraction layer between drm core and the amd
> driver is that you can't ignore if you want to refactor shared code. And
> because it's an entire world of its own, it's much harder to understand
> what the driver is doing (without reading it all). Some examples of what I
> mean:
>
> - All other drm drivers subclass drm objects (by embedding them) into the
>   corresponding hw part that most closely matches the drm object's
>   semantics. That means even when you have 0 clue about how a given piece
>   of hw works, you have a reasonable chance of understanding code. If it's
>   all your own stuff you always have to keep in minde the special amd
>   naming conventions. That gets old real fast if you trying to figure out
>   what 20+ (or are we at 30 already?) drivers are doing.
>
> - This is even more true for atomic. Atomic has a pretty complicated
>   check/commmit transactional model for updating display state. It's a
>   standardized interface, and it's extensible, and we want generic
>   userspace to be able to run on any driver. Fairly often we realize that
>   semantics of existing or newly proposed properties and state isn't
>   well-defined enough, and then we need to go all the drivers and
>   figure out how to fix up the mess. DC has it's entirely separate state
>   structures which again don't subclass the atomic core structures (afaik
>   at least). Again the same problems apply that you can't find things, and
>   that figuring out the exact semantics and spotting differences in
>   behaviour is almost impossible.
>
> - The trouble isn't just in reading code and understanding it correctly,
>   it's also in finding it. If you have your own completely different world
>   then just finding the right code is hard - cscope and grep fail to work.
>
> - Another issue is that very often we unify semantics in drivers by adding
>   some new helpers that at least dtrt for most of the drivers. If you have
>   your own world then the impendance mismatch will make sure that amd
>   drivers will have slightly different semantics, and I think that's not
>   good for the ecosystem and kms - people want to run a lot more than just
>   a boot splash with generic kms userspace, stuff like xf86-video-$vendor
>   is going out of favour heavily.
>
> Note that all this isn't about amd walking away and leaving an
> unmaintainable mess behind. Like I've said I don't think this is a big
> risk. The trouble is that having your own world makes it harder for
> everyone else to understand the amd driver, and understanding all drivers
> is very often step 1 in some big refactoring or feature addition effort.
> Because starting to refactor without understanding the problem generally
> doesn't work ;_) And you can't make this step 1 easier for others by
> promising to always maintain DC and update it to all the core changes,
> because that's only step 2.
>
> In all the DC discussions we've had thus far I haven't seen anyone address
> this issue. And this isn't just an issue in drm, it's pretty much
> established across all linux subsystems with the "no midlayer or OS
> abstraction layers in drivers" rule. There's some real solid reasons why
> such a HAl is extremely unpopular with upstream. And I haven't yet seen
> any good reason why amd needs to be different, thus far it looks like a
> textbook case, and there's been lots of vendors in lots of subsystems who
> 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Alex Deucher]

On Thu, Dec 8, 2016 at 10:34 AM, Daniel Vetter  wrote:
> On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
>> Hi Daniel,
>>
>> just a quick clarification in-line about "validation" inside atomic_commit.
>>
>> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
>> > Hi Harry,
>> >
>> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
>> > > We propose to use the Display Core (DC) driver for display support on
>> > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In 
>> > > order to
>> > > avoid a flag day the plan is to only support uGPU initially and 
>> > > transition
>> > > to older ASICs gradually.
>> > >
>> > > The DC component has received extensive testing within AMD for DCE8, 10, 
>> > > and
>> > > 11 GPUs and is being prepared for uGPU. Support should be better than
>> > > amdgpu's current display support.
>> > >
>> > >  * All of our QA effort is focused on DC
>> > >  * All of our CQE effort is focused on DC
>> > >  * All of our OEM preloads and custom engagements use DC
>> > >  * DC behavior mirrors what we do for other OSes
>> > >
>> > > The new asic utilizes a completely re-designed atom interface, so we 
>> > > cannot
>> > > easily leverage much of the existing atom-based code.
>> > >
>> > > We've introduced DC to the community earlier in 2016 and received a fair
>> > > amount of feedback. Some of what we've addressed so far are:
>> > >
>> > >  * Self-contain ASIC specific code. We did a bunch of work to pull
>> > >common sequences into dc/dce and leave ASIC specific code in
>> > >separate folders.
>> > >  * Started to expose AUX and I2C through generic kernel/drm
>> > >functionality and are mostly using that. Some of that code is still
>> > >needlessly convoluted. This cleanup is in progress.
>> > >  * Integrated Dave and Jerome’s work on removing abstraction in bios
>> > >parser.
>> > >  * Retire adapter service and asic capability
>> > >  * Remove some abstraction in GPIO
>> > >
>> > > Since a lot of our code is shared with pre- and post-silicon validation
>> > > suites changes need to be done gradually to prevent breakages due to a 
>> > > major
>> > > flag day.  This, coupled with adding support for new asics and lots of 
>> > > new
>> > > feature introductions means progress has not been as quick as we would 
>> > > have
>> > > liked. We have made a lot of progress none the less.
>> > >
>> > > The remaining concerns that were brought up during the last review that 
>> > > we
>> > > are working on addressing:
>> > >
>> > >  * Continue to cleanup and reduce the abstractions in DC where it
>> > >makes sense.
>> > >  * Removing duplicate code in I2C and AUX as we transition to using the
>> > >DRM core interfaces.  We can't fully transition until we've helped
>> > >fill in the gaps in the drm core that we need for certain features.
>> > >  * Making sure Atomic API support is correct.  Some of the semantics of
>> > >the Atomic API were not particularly clear when we started this,
>> > >however, that is improving a lot as the core drm documentation
>> > >improves.  Getting this code upstream and in the hands of more
>> > >atomic users will further help us identify and rectify any gaps we
>> > >have.
>> > >
>> > > Unfortunately we cannot expose code for uGPU yet. However refactor / 
>> > > cleanup
>> > > work on DC is public.  We're currently transitioning to a public patch
>> > > review. You can follow our progress on the amd-gfx mailing list. We value
>> > > community feedback on our work.
>> > >
>> > > As an appendix I've included a brief overview of the how the code 
>> > > currently
>> > > works to make understanding and reviewing the code easier.
>> > >
>> > > Prior discussions on DC:
>> > >
>> > >  * 
>> > > https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
>> > >  *
>> > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
>> > >
>> > > Current version of DC:
>> > >
>> > >  * 
>> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>> > >
>> > > Once Alex pulls in the latest patches:
>> > >
>> > >  * 
>> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>> > >
>> > > Best Regards,
>> > > Harry
>> > >
>> > >
>> > > 
>> > > *** Appendix: A Day in the Life of a Modeset ***
>> > > 
>> > >
>> > > Below is a high-level overview of a modeset with dc. Some of this might 
>> > > be a
>> > > little out-of-date since it's based on my XDC presentation but it should 
>> > > be
>> > > more-or-less the same.
>> > >
>> > > amdgpu_dm_atomic_commit()
>> > > {
>> > >   /* setup atomic state */
>> > >   drm_atomic_helper_prepare_planes(dev, state);
>> > >   drm_atomic_helper_swap_state(dev, state);
>> > >   drm_atomic_helper_update_legacy_modeset_state(dev, state);
>> > >

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Thu, Dec 08, 2016 at 04:41:52PM +0100, Christian König wrote:
> Am 08.12.2016 um 16:34 schrieb Daniel Vetter:
> > On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
> > > Hi Daniel,
> > > 
> > > just a quick clarification in-line about "validation" inside 
> > > atomic_commit.
> > > 
> > > On 2016-12-08 04:59 AM, Daniel Vetter wrote:
> > > > Hi Harry,
> > > > 
> > > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > > > We propose to use the Display Core (DC) driver for display support on
> > > > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In 
> > > > > order to
> > > > > avoid a flag day the plan is to only support uGPU initially and 
> > > > > transition
> > > > > to older ASICs gradually.
> > > > > 
> > > > > The DC component has received extensive testing within AMD for DCE8, 
> > > > > 10, and
> > > > > 11 GPUs and is being prepared for uGPU. Support should be better than
> > > > > amdgpu's current display support.
> > > > > 
> > > > >   * All of our QA effort is focused on DC
> > > > >   * All of our CQE effort is focused on DC
> > > > >   * All of our OEM preloads and custom engagements use DC
> > > > >   * DC behavior mirrors what we do for other OSes
> > > > > 
> > > > > The new asic utilizes a completely re-designed atom interface, so we 
> > > > > cannot
> > > > > easily leverage much of the existing atom-based code.
> > > > > 
> > > > > We've introduced DC to the community earlier in 2016 and received a 
> > > > > fair
> > > > > amount of feedback. Some of what we've addressed so far are:
> > > > > 
> > > > >   * Self-contain ASIC specific code. We did a bunch of work to pull
> > > > > common sequences into dc/dce and leave ASIC specific code in
> > > > > separate folders.
> > > > >   * Started to expose AUX and I2C through generic kernel/drm
> > > > > functionality and are mostly using that. Some of that code is 
> > > > > still
> > > > > needlessly convoluted. This cleanup is in progress.
> > > > >   * Integrated Dave and Jerome’s work on removing abstraction in bios
> > > > > parser.
> > > > >   * Retire adapter service and asic capability
> > > > >   * Remove some abstraction in GPIO
> > > > > 
> > > > > Since a lot of our code is shared with pre- and post-silicon 
> > > > > validation
> > > > > suites changes need to be done gradually to prevent breakages due to 
> > > > > a major
> > > > > flag day.  This, coupled with adding support for new asics and lots 
> > > > > of new
> > > > > feature introductions means progress has not been as quick as we 
> > > > > would have
> > > > > liked. We have made a lot of progress none the less.
> > > > > 
> > > > > The remaining concerns that were brought up during the last review 
> > > > > that we
> > > > > are working on addressing:
> > > > > 
> > > > >   * Continue to cleanup and reduce the abstractions in DC where it
> > > > > makes sense.
> > > > >   * Removing duplicate code in I2C and AUX as we transition to using 
> > > > > the
> > > > > DRM core interfaces.  We can't fully transition until we've helped
> > > > > fill in the gaps in the drm core that we need for certain 
> > > > > features.
> > > > >   * Making sure Atomic API support is correct.  Some of the semantics 
> > > > > of
> > > > > the Atomic API were not particularly clear when we started this,
> > > > > however, that is improving a lot as the core drm documentation
> > > > > improves.  Getting this code upstream and in the hands of more
> > > > > atomic users will further help us identify and rectify any gaps we
> > > > > have.
> > > > > 
> > > > > Unfortunately we cannot expose code for uGPU yet. However refactor / 
> > > > > cleanup
> > > > > work on DC is public.  We're currently transitioning to a public patch
> > > > > review. You can follow our progress on the amd-gfx mailing list. We 
> > > > > value
> > > > > community feedback on our work.
> > > > > 
> > > > > As an appendix I've included a brief overview of the how the code 
> > > > > currently
> > > > > works to make understanding and reviewing the code easier.
> > > > > 
> > > > > Prior discussions on DC:
> > > > > 
> > > > >   * 
> > > > > https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
> > > > >   *
> > > > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
> > > > > 
> > > > > Current version of DC:
> > > > > 
> > > > >   * 
> > > > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > > > 
> > > > > Once Alex pulls in the latest patches:
> > > > > 
> > > > >   * 
> > > > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > > > 
> > > > > Best Regards,
> > > > > Harry
> > > > > 
> > > > > 
> > > > > 
> > > > > *** Appendix: A Day in the Life of a Modeset ***
> > > > > 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:
> Hi Daniel,
> 
> just a quick clarification in-line about "validation" inside atomic_commit.
> 
> On 2016-12-08 04:59 AM, Daniel Vetter wrote:
> > Hi Harry,
> > 
> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > We propose to use the Display Core (DC) driver for display support on
> > > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order 
> > > to
> > > avoid a flag day the plan is to only support uGPU initially and transition
> > > to older ASICs gradually.
> > > 
> > > The DC component has received extensive testing within AMD for DCE8, 10, 
> > > and
> > > 11 GPUs and is being prepared for uGPU. Support should be better than
> > > amdgpu's current display support.
> > > 
> > >  * All of our QA effort is focused on DC
> > >  * All of our CQE effort is focused on DC
> > >  * All of our OEM preloads and custom engagements use DC
> > >  * DC behavior mirrors what we do for other OSes
> > > 
> > > The new asic utilizes a completely re-designed atom interface, so we 
> > > cannot
> > > easily leverage much of the existing atom-based code.
> > > 
> > > We've introduced DC to the community earlier in 2016 and received a fair
> > > amount of feedback. Some of what we've addressed so far are:
> > > 
> > >  * Self-contain ASIC specific code. We did a bunch of work to pull
> > >common sequences into dc/dce and leave ASIC specific code in
> > >separate folders.
> > >  * Started to expose AUX and I2C through generic kernel/drm
> > >functionality and are mostly using that. Some of that code is still
> > >needlessly convoluted. This cleanup is in progress.
> > >  * Integrated Dave and Jerome’s work on removing abstraction in bios
> > >parser.
> > >  * Retire adapter service and asic capability
> > >  * Remove some abstraction in GPIO
> > > 
> > > Since a lot of our code is shared with pre- and post-silicon validation
> > > suites changes need to be done gradually to prevent breakages due to a 
> > > major
> > > flag day.  This, coupled with adding support for new asics and lots of new
> > > feature introductions means progress has not been as quick as we would 
> > > have
> > > liked. We have made a lot of progress none the less.
> > > 
> > > The remaining concerns that were brought up during the last review that we
> > > are working on addressing:
> > > 
> > >  * Continue to cleanup and reduce the abstractions in DC where it
> > >makes sense.
> > >  * Removing duplicate code in I2C and AUX as we transition to using the
> > >DRM core interfaces.  We can't fully transition until we've helped
> > >fill in the gaps in the drm core that we need for certain features.
> > >  * Making sure Atomic API support is correct.  Some of the semantics of
> > >the Atomic API were not particularly clear when we started this,
> > >however, that is improving a lot as the core drm documentation
> > >improves.  Getting this code upstream and in the hands of more
> > >atomic users will further help us identify and rectify any gaps we
> > >have.
> > > 
> > > Unfortunately we cannot expose code for uGPU yet. However refactor / 
> > > cleanup
> > > work on DC is public.  We're currently transitioning to a public patch
> > > review. You can follow our progress on the amd-gfx mailing list. We value
> > > community feedback on our work.
> > > 
> > > As an appendix I've included a brief overview of the how the code 
> > > currently
> > > works to make understanding and reviewing the code easier.
> > > 
> > > Prior discussions on DC:
> > > 
> > >  * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
> > >  *
> > > https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
> > > 
> > > Current version of DC:
> > > 
> > >  * 
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > 
> > > Once Alex pulls in the latest patches:
> > > 
> > >  * 
> > > https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > 
> > > Best Regards,
> > > Harry
> > > 
> > > 
> > > 
> > > *** Appendix: A Day in the Life of a Modeset ***
> > > 
> > > 
> > > Below is a high-level overview of a modeset with dc. Some of this might 
> > > be a
> > > little out-of-date since it's based on my XDC presentation but it should 
> > > be
> > > more-or-less the same.
> > > 
> > > amdgpu_dm_atomic_commit()
> > > {
> > >   /* setup atomic state */
> > >   drm_atomic_helper_prepare_planes(dev, state);
> > >   drm_atomic_helper_swap_state(dev, state);
> > >   drm_atomic_helper_update_legacy_modeset_state(dev, state);
> > > 
> > >   /* create or remove targets */
> > > 
> > >   /
> > >* *** Call into DC to commit targets with list of all known 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Christian König]

Am 08.12.2016 um 16:34 schrieb Daniel Vetter:

On Thu, Dec 08, 2016 at 09:33:25AM -0500, Harry Wentland wrote:

Hi Daniel,

just a quick clarification in-line about "validation" inside atomic_commit.

On 2016-12-08 04:59 AM, Daniel Vetter wrote:

Hi Harry,

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:

We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
avoid a flag day the plan is to only support uGPU initially and transition
to older ASICs gradually.

The DC component has received extensive testing within AMD for DCE8, 10, and
11 GPUs and is being prepared for uGPU. Support should be better than
amdgpu's current display support.

  * All of our QA effort is focused on DC
  * All of our CQE effort is focused on DC
  * All of our OEM preloads and custom engagements use DC
  * DC behavior mirrors what we do for other OSes

The new asic utilizes a completely re-designed atom interface, so we cannot
easily leverage much of the existing atom-based code.

We've introduced DC to the community earlier in 2016 and received a fair
amount of feedback. Some of what we've addressed so far are:

  * Self-contain ASIC specific code. We did a bunch of work to pull
common sequences into dc/dce and leave ASIC specific code in
separate folders.
  * Started to expose AUX and I2C through generic kernel/drm
functionality and are mostly using that. Some of that code is still
needlessly convoluted. This cleanup is in progress.
  * Integrated Dave and Jerome’s work on removing abstraction in bios
parser.
  * Retire adapter service and asic capability
  * Remove some abstraction in GPIO

Since a lot of our code is shared with pre- and post-silicon validation
suites changes need to be done gradually to prevent breakages due to a major
flag day.  This, coupled with adding support for new asics and lots of new
feature introductions means progress has not been as quick as we would have
liked. We have made a lot of progress none the less.

The remaining concerns that were brought up during the last review that we
are working on addressing:

  * Continue to cleanup and reduce the abstractions in DC where it
makes sense.
  * Removing duplicate code in I2C and AUX as we transition to using the
DRM core interfaces.  We can't fully transition until we've helped
fill in the gaps in the drm core that we need for certain features.
  * Making sure Atomic API support is correct.  Some of the semantics of
the Atomic API were not particularly clear when we started this,
however, that is improving a lot as the core drm documentation
improves.  Getting this code upstream and in the hands of more
atomic users will further help us identify and rectify any gaps we
have.

Unfortunately we cannot expose code for uGPU yet. However refactor / cleanup
work on DC is public.  We're currently transitioning to a public patch
review. You can follow our progress on the amd-gfx mailing list. We value
community feedback on our work.

As an appendix I've included a brief overview of the how the code currently
works to make understanding and reviewing the code easier.

Prior discussions on DC:

  * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
  *
https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html

Current version of DC:

  * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Once Alex pulls in the latest patches:

  * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Best Regards,
Harry



*** Appendix: A Day in the Life of a Modeset ***


Below is a high-level overview of a modeset with dc. Some of this might be a
little out-of-date since it's based on my XDC presentation but it should be
more-or-less the same.

amdgpu_dm_atomic_commit()
{
   /* setup atomic state */
   drm_atomic_helper_prepare_planes(dev, state);
   drm_atomic_helper_swap_state(dev, state);
   drm_atomic_helper_update_legacy_modeset_state(dev, state);

   /* create or remove targets */

   /
* *** Call into DC to commit targets with list of all known targets
/
   /* DC is optimized not to do anything if 'targets' didn't change. */
   dc_commit_targets(dm->dc, commit_targets, commit_targets_count)
   {
 /**
  * *** Build context (function also used for validation)
  **/
 result = core_dc->res_pool->funcs->validate_with_context(
core_dc,set,target_count,context);

I can't dig into details 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

Hi Daniel,

just a quick clarification in-line about "validation" inside atomic_commit.

On 2016-12-08 04:59 AM, Daniel Vetter wrote:

Hi Harry,

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:

We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
avoid a flag day the plan is to only support uGPU initially and transition
to older ASICs gradually.

The DC component has received extensive testing within AMD for DCE8, 10, and
11 GPUs and is being prepared for uGPU. Support should be better than
amdgpu's current display support.

 * All of our QA effort is focused on DC
 * All of our CQE effort is focused on DC
 * All of our OEM preloads and custom engagements use DC
 * DC behavior mirrors what we do for other OSes

The new asic utilizes a completely re-designed atom interface, so we cannot
easily leverage much of the existing atom-based code.

We've introduced DC to the community earlier in 2016 and received a fair
amount of feedback. Some of what we've addressed so far are:

 * Self-contain ASIC specific code. We did a bunch of work to pull
   common sequences into dc/dce and leave ASIC specific code in
   separate folders.
 * Started to expose AUX and I2C through generic kernel/drm
   functionality and are mostly using that. Some of that code is still
   needlessly convoluted. This cleanup is in progress.
 * Integrated Dave and Jerome’s work on removing abstraction in bios
   parser.
 * Retire adapter service and asic capability
 * Remove some abstraction in GPIO

Since a lot of our code is shared with pre- and post-silicon validation
suites changes need to be done gradually to prevent breakages due to a major
flag day.  This, coupled with adding support for new asics and lots of new
feature introductions means progress has not been as quick as we would have
liked. We have made a lot of progress none the less.

The remaining concerns that were brought up during the last review that we
are working on addressing:

 * Continue to cleanup and reduce the abstractions in DC where it
   makes sense.
 * Removing duplicate code in I2C and AUX as we transition to using the
   DRM core interfaces.  We can't fully transition until we've helped
   fill in the gaps in the drm core that we need for certain features.
 * Making sure Atomic API support is correct.  Some of the semantics of
   the Atomic API were not particularly clear when we started this,
   however, that is improving a lot as the core drm documentation
   improves.  Getting this code upstream and in the hands of more
   atomic users will further help us identify and rectify any gaps we
   have.

Unfortunately we cannot expose code for uGPU yet. However refactor / cleanup
work on DC is public.  We're currently transitioning to a public patch
review. You can follow our progress on the amd-gfx mailing list. We value
community feedback on our work.

As an appendix I've included a brief overview of the how the code currently
works to make understanding and reviewing the code easier.

Prior discussions on DC:

 * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
 *
https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html

Current version of DC:

 * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Once Alex pulls in the latest patches:

 * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Best Regards,
Harry



*** Appendix: A Day in the Life of a Modeset ***


Below is a high-level overview of a modeset with dc. Some of this might be a
little out-of-date since it's based on my XDC presentation but it should be
more-or-less the same.

amdgpu_dm_atomic_commit()
{
  /* setup atomic state */
  drm_atomic_helper_prepare_planes(dev, state);
  drm_atomic_helper_swap_state(dev, state);
  drm_atomic_helper_update_legacy_modeset_state(dev, state);

  /* create or remove targets */

  /
   * *** Call into DC to commit targets with list of all known targets
   /
  /* DC is optimized not to do anything if 'targets' didn't change. */
  dc_commit_targets(dm->dc, commit_targets, commit_targets_count)
  {
/**
 * *** Build context (function also used for validation)
 **/
result = core_dc->res_pool->funcs->validate_with_context(
   core_dc,set,target_count,context);


I can't dig into details of DC, so this is not a 100% assessment, but if
you call a function called "validate" in atomic_commit, you're very, very
likely breaking atomic. _All_ 

Re: [RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

Hi Harry,

On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to older ASICs gradually.
> 
> The DC component has received extensive testing within AMD for DCE8, 10, and
> 11 GPUs and is being prepared for uGPU. Support should be better than
> amdgpu's current display support.
> 
>  * All of our QA effort is focused on DC
>  * All of our CQE effort is focused on DC
>  * All of our OEM preloads and custom engagements use DC
>  * DC behavior mirrors what we do for other OSes
> 
> The new asic utilizes a completely re-designed atom interface, so we cannot
> easily leverage much of the existing atom-based code.
> 
> We've introduced DC to the community earlier in 2016 and received a fair
> amount of feedback. Some of what we've addressed so far are:
> 
>  * Self-contain ASIC specific code. We did a bunch of work to pull
>common sequences into dc/dce and leave ASIC specific code in
>separate folders.
>  * Started to expose AUX and I2C through generic kernel/drm
>functionality and are mostly using that. Some of that code is still
>needlessly convoluted. This cleanup is in progress.
>  * Integrated Dave and Jerome’s work on removing abstraction in bios
>parser.
>  * Retire adapter service and asic capability
>  * Remove some abstraction in GPIO
> 
> Since a lot of our code is shared with pre- and post-silicon validation
> suites changes need to be done gradually to prevent breakages due to a major
> flag day.  This, coupled with adding support for new asics and lots of new
> feature introductions means progress has not been as quick as we would have
> liked. We have made a lot of progress none the less.
> 
> The remaining concerns that were brought up during the last review that we
> are working on addressing:
> 
>  * Continue to cleanup and reduce the abstractions in DC where it
>makes sense.
>  * Removing duplicate code in I2C and AUX as we transition to using the
>DRM core interfaces.  We can't fully transition until we've helped
>fill in the gaps in the drm core that we need for certain features.
>  * Making sure Atomic API support is correct.  Some of the semantics of
>the Atomic API were not particularly clear when we started this,
>however, that is improving a lot as the core drm documentation
>improves.  Getting this code upstream and in the hands of more
>atomic users will further help us identify and rectify any gaps we
>have.
> 
> Unfortunately we cannot expose code for uGPU yet. However refactor / cleanup
> work on DC is public.  We're currently transitioning to a public patch
> review. You can follow our progress on the amd-gfx mailing list. We value
> community feedback on our work.
> 
> As an appendix I've included a brief overview of the how the code currently
> works to make understanding and reviewing the code easier.
> 
> Prior discussions on DC:
> 
>  * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
>  *
> https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html
> 
> Current version of DC:
> 
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> 
> Once Alex pulls in the latest patches:
> 
>  * 
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> 
> Best Regards,
> Harry
> 
> 
> 
> *** Appendix: A Day in the Life of a Modeset ***
> 
> 
> Below is a high-level overview of a modeset with dc. Some of this might be a
> little out-of-date since it's based on my XDC presentation but it should be
> more-or-less the same.
> 
> amdgpu_dm_atomic_commit()
> {
>   /* setup atomic state */
>   drm_atomic_helper_prepare_planes(dev, state);
>   drm_atomic_helper_swap_state(dev, state);
>   drm_atomic_helper_update_legacy_modeset_state(dev, state);
> 
>   /* create or remove targets */
> 
>   /
>* *** Call into DC to commit targets with list of all known targets
>/
>   /* DC is optimized not to do anything if 'targets' didn't change. */
>   dc_commit_targets(dm->dc, commit_targets, commit_targets_count)
>   {
> /**
>  * *** Build context (function also used for validation)
>  **/
> result = core_dc->res_pool->funcs->validate_with_context(
>core_dc,set,target_count,context);

I can't dig into details of DC, so this is not a 100% assessment, but if
you call a function called