On Tue, 3 Jun 2025 at 18:50, Christian König wrote:
>
> On 6/3/25 09:52, David Airlie wrote:
> > On Tue, Jun 3, 2025 at 5:47 PM Christian König
> > wrote:
> >>
> >> On 6/2/25 22:40, Dave Airlie wrote:
> >>> From: Dave Airlie
> >>>
> >>> Currently you can't see per-device numa aware pools proper
On 6/3/25 09:52, David Airlie wrote:
> On Tue, Jun 3, 2025 at 5:47 PM Christian König
> wrote:
>>
>> On 6/2/25 22:40, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> Currently you can't see per-device numa aware pools properly.
>>>
>>> Cc: Christian König
>>> Signed-off-by: Dave Airlie
>>
>>
On Tue, Jun 3, 2025 at 5:47 PM Christian König wrote:
>
> On 6/2/25 22:40, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Currently you can't see per-device numa aware pools properly.
> >
> > Cc: Christian König
> > Signed-off-by: Dave Airlie
>
> Reviewed-by: Christian König
>
> Any follow u
On 6/2/25 22:40, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently you can't see per-device numa aware pools properly.
>
> Cc: Christian König
> Signed-off-by: Dave Airlie
Reviewed-by: Christian König
Any follow up patch to wire this up in amdgpu?
Regards,
Christian.
> ---
> drivers/g
Am 03.03.23 um 11:12 schrieb suijingfeng:
should replace '@' with '*'
Signed-off-by: suijingfeng
I've just reviewed and pushed the patch to drm-misc-next.
Just please use your full (first and last) name for author and
signed-off-by tags in the future.
Thanks,
Christian.
---
include/
Am 19.03.22 um 08:31 schrieb Xiaomeng Tong:
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based o
Patch looks good to me too.
Reviewed-by: Roland Scheidegger
Seems indeed like we should do some cleanup.
Roland
Am 28.07.20 um 09:37 schrieb Christian König:
> Am 28.07.20 um 05:42 schrieb Dave Airlie:
>> From: Dave Airlie
>>
>> Just drop the argument from this.
>>
>> This does ask the questio
> On Jul 27, 2020, at 11:42 PM, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yea, it really should. This code is real
On Tue, Jul 28, 2020 at 01:42:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yeah this looks a bit like ttm_bo_s
Am 28.07.20 um 05:42 schrieb Dave Airlie:
From: Dave Airlie
Just drop the argument from this.
This does ask the question if this is the function vmwgfx
should be using or should it be doing an evict all like
the other drivers.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
adding a wrapper for pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
-------- Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow
u_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while
gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,&qu
in ttm has this risk, how about just adding a wrapper for
pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message
Subject: Re: [PATCH]
ctx->resv inline to address your
concern? As well as don't wait from same user, shouldn't lead to
deadlock.
Otherwise, any other idea?
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu
busy
From: Christian König
To: "Liang, Pri
erve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message --------
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koeni
y not trivial, but doable as far as I can see.
>>
>> Have fun :)
>> Christian.
>>
>> Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):
>>
>> How about adding more condition ctx->resv inline to address your concern? As
>> well as don't wait from same user, s
fun :)
> Christian.
>
> Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):
>
> How about adding more condition ctx->resv inline to address your concern? As
> well as don't wait from same user, shouldn't lead to deadlock.
>
> Otherwise, any other idea?
&g
function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian K
u_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"L
has this risk, how about just adding a
wrapper for pin function as below?
amdgpu_get_pin_bo_timeout()
{
do {
amdgpo_bo_reserve();
r=amdgpu_bo_pin();
if(!r)
break;
amdgpu_bo_unreserve();
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: w
timeout--;
} while(timeout>0);
}
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org
CC:
We
l Message
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Christian König
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang, Prike"
,dri-devel@lists.freedesktop.org
CC:
Well that's not so easy of hand.
The basic problem here is t
eb Zhou, David(ChunMing):
How about adding more condition ctx->resv inline to address your
concern? As well as don't wait from same user, shouldn't lead to deadlock.
Otherwise, any other idea?
Original Message
Subject: Re: [PATCH] ttm: wait mem space if user allow
How about adding more condition ctx->resv inline to address your concern? As
well as don't wait from same user, shouldn't lead to deadlock.
Otherwise, any other idea?
Original Message ----
Subject: Re: [PATCH] ttm: wait mem space if user allow while gpu busy
From: Ch
Well that is certainly a NAK because it can lead to deadlock in the
memory management.
You can't just busy wait with all those locks held.
Regards,
Christian.
Am 23.04.19 um 03:45 schrieb Liang, Prike:
Acked-by: Prike Liang
Thanks,
Prike
-Original Message-
From: Chunming Zhou
Sent:
Acked-by: Prike Liang
Thanks,
Prike
-Original Message-
From: Chunming Zhou
Sent: Monday, April 22, 2019 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Liang, Prike ; Zhou, David(ChunMing)
Subject: [PATCH] ttm: wait mem space if user allow while gpu busy
heavy gpu job could occupy me
On Wed, Jan 16, 2013 at 1:01 AM, Dave Airlie wrote:
> if we have a move notify callback, when moving fails, we call move notify
> the opposite way around, however this ends up with *mem containing the mm_node
> from the bo, which means we double free it. This is a follow on to the
> previous
> fi
On Tue, Jan 15, 2013 at 11:28 PM, Dave Airlie wrote:
> When we are using memcpy to move objects around, and we fail to memcpy
> due to lack of memory to populate or failure to finish the copy, we don't
> want to destroy the mm_node that has been copied into old_copy.
>
> While working on a new kms
On Thu, Jan 12, 2012 at 11:50:26AM -0500, Konrad Rzeszutek Wilk wrote:
> . It was useful during development, but now on a production system
> we can get this (if the user forgot to upload the firmware):
>
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
On Wed, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
Hmm, seems a part of this got eaten by the Internet monsters.
Since v2.0: [not posted]
- Redid the registration/override to be tightly integrated with the
'struct ttm_backend_func' per Thomas's suggestion.
Since v1.9: [not
On 10/03/2011 06:46 PM, Konrad Rzeszutek Wilk wrote:
It does now (I had a spinlock mishap).. which reminds me - how
do I test these patches with your vmwgfx driver? I've an old version
of VMWare Workstation 8, would that do?
VMware workstation 8 is OK (it's actually the latest version of
On Mon, Oct 03, 2011 at 06:35:42PM +0200, Thomas Hellstrom wrote:
> On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> >>Konrad,
> >>
> >>I'm really sorry for taking so long to review this.
> >That is OK. We all are busy - and
On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
Konrad,
I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
I'd like to
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
>
> I'd like to go through a couple of high-level things first before
> rev
Konrad,
I'm really sorry for taking so long to review this.
I'd like to go through a couple of high-level things first before
reviewing the coding itself.
The page_alloc_func structure looks nice, but I'd like to have it per
ttm backend,
we would just need to make sure that the backend is al
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/tt
38 matches
Mail list logo
