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 w
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 work right.
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,
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 Wentl
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 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:
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
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
, 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,
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 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
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 a
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
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 th
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
(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 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 sup
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.freedes
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
ts.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
&
dzovsky, 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:
>
dzovsky, 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:
>
eedesktop.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
>
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@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:
&g
>
>>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
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 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 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 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 al
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 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
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
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
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.
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
> 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
> -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] U
>
> 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
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
> 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 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
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 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:
> >
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
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 GP
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
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 testin
61 matches
Mail list logo
