On Tue, Apr 14, 2020 at 4:29 PM Kenny Ho wrote:
>
> On Tue, Apr 14, 2020 at 10:04 AM Daniel Vetter wrote:
> >
> > This has _nothing_ to do with Intel (I think over the past 25 years or
> > so intel has implemented all 4 versions of gpu splitting that I
> > listed, but not entirely sure).
> >
> >
On Tue, Apr 14, 2020 at 10:04 AM Daniel Vetter wrote:
>
> This has _nothing_ to do with Intel (I think over the past 25 years or
> so intel has implemented all 4 versions of gpu splitting that I
> listed, but not entirely sure).
>
> So again pls less tribal fighting, more collaboration. If you can
On Tue, Apr 14, 2020 at 3:50 PM Kenny Ho wrote:
>
> Hi Daniel,
>
> I appreciate many of your review so far and I much prefer keeping
> things technical but that is very difficult to do when I get Intel
> developers calling my implementation "most AMD-specific solution
> possible" and objecting to
Hi Daniel,
I appreciate many of your review so far and I much prefer keeping
things technical but that is very difficult to do when I get Intel
developers calling my implementation "most AMD-specific solution
possible" and objecting to an implementation because their hardware
cannot support it. C
On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho wrote:
>
> Ok. I was hoping you can clarify the contradiction between the
> existance of the spec below and your "not something any other gpu can
> reasonably support" statement. I mean, OneAPI is Intel's spec and
> doesn't that at least make SubDevice su
Ok. I was hoping you can clarify the contradiction between the
existance of the spec below and your "not something any other gpu can
reasonably support" statement. I mean, OneAPI is Intel's spec and
doesn't that at least make SubDevice support "reasonable" for one more
vendor?
Partisanship aside
On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho wrote:
> On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter wrote:
> > My understanding from talking with a few other folks is that
> > the cpumask-style CU-weight thing is not something any other gpu can
> > reasonably support (and we have about 6+ of those in
Hi Daniel,
On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter wrote:
> My understanding from talking with a few other folks is that
> the cpumask-style CU-weight thing is not something any other gpu can
> reasonably support (and we have about 6+ of those in-tree)
How does Intel plan to support the Su
On Mon, Apr 13, 2020 at 03:11:36PM -0400, Tejun Heo wrote:
> Hello, Kenny.
>
> On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> > Can you elaborate more on what are the missing pieces?
>
> Sorry about the long delay, but I think we've been going in circles for quite
> a while now. Let'
Hello,
On Mon, Apr 13, 2020 at 05:40:32PM -0400, Kenny Ho wrote:
> By lack of consense, do you mean Intel's assertion that a standard is
> not a standard until Intel implements it? (That was in the context of
> OpenCL language standard with the concept of SubDevice.) I thought
> the discussion so
Hi,
On Mon, Apr 13, 2020 at 4:54 PM Tejun Heo wrote:
>
> Allocations definitely are acceptable and it's not a pre-requisite to have
> work-conserving control first either. Here, given the lack of consensus in
> terms of what even constitute resource units, I don't think it'd be a good
> idea to c
Hello,
On Mon, Apr 13, 2020 at 04:17:14PM -0400, Kenny Ho wrote:
> Perhaps we can even narrow things down to just
> gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
That sounds great to me.
> objection to the current implementation of gpu.compute.weight the
> work-conserving
(replying again in plain-text)
Hi Tejun,
Thanks for taking the time to reply.
Perhaps we can even narrow things down to just
gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
objection to the current implementation of gpu.compute.weight the
work-conserving bit? This work-con
rnel.org
; dri-devel ; amd-gfx
list ; Deucher, Alexander
; Koenig, Christian ;
Kuehling, Felix ; Greathouse, Joseph
; jspa...@cray.com
Subject: Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hello, Kenny.
On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> Can
Hello, Kenny.
On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> Can you elaborate more on what are the missing pieces?
Sorry about the long delay, but I think we've been going in circles for quite
a while now. Let's try to make it really simple as the first step. How about
something lik
Hi Tejun,
Can you elaborate more on what are the missing pieces?
Regards,
Kenny
On Tue, Mar 24, 2020 at 2:46 PM Tejun Heo wrote:
>
> On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote:
> > What's your thoughts on this latest series?
>
> My overall impression is that the feedbacks aren't b
On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote:
> What's your thoughts on this latest series?
My overall impression is that the feedbacks aren't being incorporated throughly
/ sufficiently.
Thanks.
--
tejun
___
dri-devel mailing list
dri-dev
Hi Tejun,
What's your thoughts on this latest series?
Regards,
Kenny
On Wed, Feb 26, 2020 at 2:02 PM Kenny Ho wrote:
>
> This is a submission for the introduction of a new cgroup controller for the
> drm subsystem follow a series of RFCs [v1, v2, v3, v4]
>
> Changes from PR v1
> * changed cgro
This is a submission for the introduction of a new cgroup controller for the
drm subsystem follow a series of RFCs [v1, v2, v3, v4]
Changes from PR v1
* changed cgroup controller name from drm to gpu
* removed lgpu
* added compute.weight resources, clarified resources being distributed as
partit
19 matches
Mail list logo
