Hi,
I have been reading the ongoing discussion about what to do about AMD DC
(Display Core) with great interest since I have started to put more time into
developing OpenChrome DRM for VIA Technologies Chrome IGP.
I particularly enjoyed reading what Tony Cheng wrote about what is going on
insid
list ; dri-devel
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
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
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 ar
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 w
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
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:0
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
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
(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, resourc
> 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
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 thos
On 10/12/16 01:32 AM, Jan Ziak wrote:
> Hello Dave
>
> Let's cool down the discussion a bit and try to work out a solution.
>
> To summarize the facts, your decision implies that the probability of
> merging DAL/DC into the mainline Linux kernel the next year (2017) has
> become extremely low.
>
ovsky, 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
, Andrey; amd-gfx mailing list;
dri-devel; Deucher, Alexander
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
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,
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 2
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
2016-12-13 3:33 GMT+01:00 Harry Wentland :
Please keep asking us to get on dri-devel with questions. I need to get
> into the habit again of leaving the IRC channel open. I think most of us
> are still a bit scared of it or don't know how to deal with some of the
> information overload (IRC and ma
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 t
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 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 t
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/am
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 t
On Mon, Dec 12, 2016 at 09:33:52PM -0500, 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 uGP
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.
>>
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 t
On 12/11/2016 9:57 PM, Dave Airlie wrote:
> On 8 December 2016 at 12:02, 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
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
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:
>>
>> *
Hi Dave,
Apologies for waking you up with the RFC on a Friday morning. I'll try
to time big stuff better next time.
A couple of thoughts below after having some discussions internally. I
think Tony might add to some of them or provide his own.
On 2016-12-11 09:57 PM, Dave Airlie wrote:
> On 8
vel at 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-bounces at lists.freedesktop.org] On
> Behalf
> >> Of
y, Andrey; Cheng, Tony; dri-devel at lists.freedesktop.org; amd-
>> gfx at 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:
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
>
>
>>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.
>
>
> Can we say "restructuring" just for consistency with Daniel's message (the
> HW-dependent bits don't need to be rewritten bu
On 8 December 2016 at 12:02, 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 gr
On Mon, Dec 12, 2016 at 10:27:27AM +0100, Daniel Vetter wrote:
> 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
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 upst
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/driv
On Mon, Dec 12, 2016 at 12:57:40PM +1000, Dave Airlie wrote:
> 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 st
2:22 AM
To: Wentland, Harry
Cc: Grodzovsky, Andrey; amd-gfx at lists.freedesktop.org; dri-devel at
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
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
Thanks Dave. Apologies in advance for top posting but I'm stuck on a mail
client that makes a big mess when I try anything else...
>This code needs rewriting, not cleaning, not polishing, it needs to be
>split into its constituent
Cheng,
Tony; Cyr, Aric; Grodzovsky, Andrey
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
Thanks Dave. Apologies in advance for top posting but I'm stuck on a mail
client that makes a big mess when I try anything else...
>If DC was ready for the next-gen GPU it would be ready
h only supports cards that
people can't buy yet.
From: Dave Airlie
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
Su
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 ol
On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie airlied at gmail.com> wrote:
> On 10 December 2016 at 05:59, Daniel Vetter 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
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 the
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 the
> 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 co
On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie wrote:
> I actually love bandwidth_calcs.c I'd like to merge it even before DAL, yes
> it's ugly code, and it's horrible but it's a single piece of hw team magic,
> and
> we can hide that. It's the sw abstraction magic that is my issue.
If anyone wants
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.
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
> 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 yea
Hello Dave
Let's cool down the discussion a bit and try to work out a solution.
To summarize the facts, your decision implies that the probability of
merging DAL/DC into the mainline Linux kernel the next year (2017) has
become extremely low.
In essence, the strategy you are implicitly proposing
> -Original Message-
> From: Dave Airlie [mailto:airlied at 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] U
> 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 yea
On Fri, 09 Dec 2016 12:34:17 -0800 Dave Airlie
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 replaci
>
> 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 re
> 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
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.
> >
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, 20
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:
> >
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
putation code between check and commit doesn't get out of sync.
> >
> >> As for the rest, I hear you and appreciate your feedback. Let me get back
> >> to
> >> you on that later.
> > Just an added note on that: I do think that there's some driver teams
> > who've managed to pull a shared cod
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 transit
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 upc
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
65 matches
Mail list logo
