> -Original Message-
> From: amd-gfx On Behalf Of Rex
> Zhu
> Sent: Wednesday, October 24, 2018 2:03 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet
>
> the csa buffer is used by sdma engine to do context save wh
the csa buffer is used by sdma engine to do context
save when preemption happens. it the mc address is zero,
mean the preemtpion feature(MCBP) is disabled.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 ++
dr
On 10/4/18 9:12 PM, Christian König wrote:
And drop the now superflous extra reservations.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 ++-
2 files changed, 6 insertions(+), 13 deletions(-)
dif
Patch 3, 5 is
Acked-by: Junwei Zhang
Others are
Reviewed-by: Junwei Zhang
On 10/4/18 9:12 PM, Christian König wrote:
No need for that any more. Just replace the list when there isn't enough
room any more for the additional fence.
Signed-off-by: Christian König
---
drivers/dma-buf/reservat
Christian, I will take a look at them later.
Thanks,
Ray
> -Original Message-
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Tuesday, October 23, 2018 8:20 PM
> To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> me...@vger.kernel.org; l
On 10/24/18 3:07 AM, Marek Olšák wrote:
From: Marek Olšák
commit log and sign-off here as well.
And any reason for that?
Regards,
Jerry
---
amdgpu/amdgpu_bo.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
inde
On 10/24/18 3:07 AM, Marek Olšák wrote:
From: Marek Olšák
We need commit log and sign-off here.
BTW, have you encounter any issue about that?
---
amdgpu/amdgpu_bo.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgp
Revised accordingly, and pushed. Thanks!
Yong
From: Kuehling, Felix
Sent: Tuesday, October 23, 2018 4:37:45 PM
To: Zhao, Yong; brahma_sw_dev; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/amdgpu: Reorganize *_flush_gpu_tlb() for kfd to use
It occurr
Pushed. Thanks!
Yong
From: Kuehling, Felix
Sent: Tuesday, October 23, 2018 4:43:05 PM
To: Zhao, Yong; amd-gfx@lists.freedesktop.org; brahma_sw_dev
Subject: Re: [PATCH 2/2] drm/amdkfd: page_table_base already have the flags
needed
The series is Reviewed-by: Feli
I'm working on a vm fault issue that this tlb flush type can have
effect on this , do we plan to make a kernel parameter for this ?
Regards
shaoyun.liu
On 2018-10-23 4:37 p.m., Kuehling, Felix wrote:
> It occurred to me that the flush_type is a hardware-specific value, but
> you're using it i
The series is Reviewed-by: Felix Kuehling
On 2018-10-23 1:00 p.m., Zhao, Yong wrote:
>
> How about those two patches?
>
>
> Yong
>
>
> *From:* Zhao, Yong
> *Sent:* Monday, October 22, 2018 2:33:26 PM
> *To:* amd-gfx@lists.f
It occurred to me that the flush_type is a hardware-specific value, but
you're using it in a hardware-abstracted interface. If the meaning of
the flush type values changes in future HW-generations, we'll need to
define an abstract enum that gets translated to the respective HW values
in the HW-spec
As part of the change, we stop taking the srbm lock, and start to use
the same invalidation engine and software lock.
Change-Id: I306305e43d4b4032316909b3f4e3f9f5ca4520ae
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 37 +--
1 file changed,
Add a flush_type parameter to that series of functions.
Change-Id: I3dcd71955297c53b181f82e7078981230c642c01
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c| 5 +++--
d
Series is:
Reviewed-by: Alex Deucher
From: Zhao, Yong
Sent: Tuesday, October 23, 2018 2:15:59 PM
To: brahma_sw_dev; amd-gfx@lists.freedesktop.org
Cc: Zhao, Yong
Subject: [PATCH 2/2] drm/amdkfd: Use functions from amdgpu to invalidate vmid
in kfd
As part of the
From: Marek Olšák
---
amdgpu/amdgpu_bo.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 81f8a5f7..00b9b54a 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -91,26 +91,29 @@ drm_public int amdgpu_bo_allo
From: Marek Olšák
---
amdgpu/amdgpu_bo.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index c0f42e81..81f8a5f7 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -22,20 +22,21 @@
*
*/
#include
#
Reviewed-by: Marek Olšák
Marek
On Tue, Oct 23, 2018 at 10:05 AM Nicholas Kazlauskas <
nicholas.kazlaus...@amd.com> wrote:
> [Why]
> Hardware support for Delta Color Compression (DCC) decompression is
> available in DC for GFX9 but there's no way for userspace to enable
> the feature.
>
> Enabli
How about those two patches?
Yong
From: Zhao, Yong
Sent: Monday, October 22, 2018 2:33:26 PM
To: amd-gfx@lists.freedesktop.org; brahma_sw_dev
Cc: Zhao, Yong
Subject: [PATCH 2/2] drm/amdkfd: page_table_base already have the flags needed
The flags are added when c
On Tue, Oct 23, 2018 at 12:51 PM Andrey Grodzovsky
wrote:
>
> After testing looks like these subset of ASICs has GPU reset
> working for the most part. Enable reset due to job timeout.
>
> v2: Switch from GFX version to ASIC type.
>
> Signed-off-by: Andrey Grodzovsky
Acked-by: Alex Deucher
> -
After testing looks like these subset of ASICs has GPU reset
working for the most part. Enable reset due to job timeout.
v2: Switch from GFX version to ASIC type.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 ++
1 file changed,
On 10/22/2018 05:33 AM, Koenig, Christian wrote:
> Am 19.10.18 um 22:52 schrieb Andrey Grodzovsky:
>> Problem:
>> A particular scheduler may become unsuable (underlying HW) after
>> some event (e.g. GPU reset). If it's later chosen by
>> the get free sched. policy a command will fail to be
>> sub
Am 22.10.18 um 20:41 schrieb Zhao, Yong:
> Change-Id: I3dcd71955297c53b181f82e7078981230c642c01
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 64
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h | 3 ++
> 2 files changed, 40 insertion
On 10/23/2018 05:23 AM, Christian König wrote:
> Am 22.10.18 um 22:46 schrieb Andrey Grodzovsky:
>> Start using drm_gpu_scheduler.ready isntead.
>>
>> v3:
>> Add helper function to run ring test and set
>> sched.ready flag status accordingly, clean explicit
>> sched.ready sets from the IP specifi
[Why]
Hardware support for Delta Color Compression (DCC) decompression is
available in DC for GFX9 but there's no way for userspace to enable
the feature.
Enabling the feature can provide improved GFX performance and
power savings in many situations.
[How]
Extend the GFX9 tiling flags to include
On 2018-10-04 3:12 p.m., Christian König wrote:
> It is perfectly possible that the BO list is created before the BO is
> exported. While at it cleanup setting shared to one instead of true.
"clean up"
> v2: add comment and simplify logic
>
> Signed-off-by: Christian König
As this is a bug fi
On 2018-10-23 2:20 p.m., Christian König wrote:
> Ping once more! Adding a few more AMD people.
>
> Any comments on this?
Patches 1 & 3 are a bit over my head I'm afraid.
Patches 2, 4, 6-8 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.am
Ok, I will refine the patch as you suggested.
Thanks.
Best Regards
Rex
From: amd-gfx on behalf of Koenig,
Christian
Sent: Tuesday, October 23, 2018 9:05 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of
Another concern is more and more parameters may be added to the the common
interface.
Yeah, that is a rather good argument.
Well in this case please add a wrapper for figuring out the VMID and add the
job before the ib on the parameter list.
Christian.
Am 23.10.18 um 14:55 schrieb Zhu, Rex:
>Yeah, but that can be calculated in the ring specific function. Can't it?
Yes, we should reserve and map the CSA buffer for gfx/compute/sdma together.
Another concern is more and more parameters may be added to the the common
interface.
Best Regards
Rex
F
Am 23.10.18 um 14:43 schrieb Zhu, Rex:
>Maybe indeed provide the CSA address as parameter instead. It doesn't
>really matter that it is unused by most IP block implementations.
>Alternative is to use a wrapper function to get the VMID from the job.
I preferred to use a wrapper function to get v
>Maybe indeed provide the CSA address as parameter instead. It doesn't
>really matter that it is unused by most IP block implementations.
>Alternative is to use a wrapper function to get the VMID from the job.
I preferred to use a wrapper function to get vmid.
Because if use CSA address as par
Ping once more! Adding a few more AMD people.
Any comments on this?
Thanks,
Christian.
Am 12.10.18 um 10:22 schrieb Christian König:
Ping! Adding a few people directly and more mailing lists.
Can I get an acked-by/rb for this? It's only a cleanup and not much
functional change.
Regards,
Ch
Am 23.10.18 um 14:01 schrieb Rex Zhu:
use the point of struct amdgpu_job as the function
argument instand of vmid, so the other members of
struct amdgpu_job can be visit in emit_ib function.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 +--
drivers/gpu/drm/amd/amd
use the point of struct amdgpu_job as the function
argument instand of vmid, so the other members of
struct amdgpu_job can be visit in emit_ib function.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
drivers/gpu/drm
Am 22.10.18 um 22:46 schrieb Andrey Grodzovsky:
Start using drm_gpu_scheduler.ready isntead.
v3:
Add helper function to run ring test and set
sched.ready flag status accordingly, clean explicit
sched.ready sets from the IP specific files.
Signed-off-by: Andrey Grodzovsky
---
[SNIP]
+
+int a
Am 23.10.18 um 08:22 schrieb Thomas Zimmermann:
Hi Christian
Am 19.10.18 um 18:41 schrieb Christian König:
As the name says we only need one global instance of ttm_mem_global.
Drop all the driver initialization and just use a single exported
instance which is initialized during BO global initi
Hi Christian,
You can reproduce this issue by allocate CSA buffer in baremetal and map them
to reserved VM address.
Please see the attached patch.
Best Regards
Rex
From: Christian König
Sent: Tuesday, October 23, 2018 5:01 PM
To: Zhu, Rex; Zhang, Jerry;
Hi guys,
yeah the root PD doesn't necessarily have a power of two entries.
But what exactly was the problem with the original code? Why does
0x doesn't work?
The only possible explanation I can see is that somebody tried to use an
address which is above max_pfn, or how did that trigg
On 2018-10-23 09:45, Joe Perches wrote:
On Mon, 2018-10-22 at 22:53 +0530, Arun KS wrote:
Remove managed_page_count_lock spinlock and instead use atomic
variables.
Hello Joe,
Perhaps better to define and use macros for the accesses
instead of specific uses of atomic_long_
Something like:
Arun KS writes:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
>
> Suggested-by: Michal Hocko
> Suggested-by: Vlastimil Babka
> Signed-off-by: Arun KS
>
> ---
> As discussed here,
> https://patchwork.kernel.org/patch/10627521/#22261253
My 2 cents. I think you s
On Mon, 2018-10-22 at 22:53 +0530, Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
Perhaps better to define and use macros for the accesses
instead of specific uses of atomic_long_
Something like:
#define totalram_pages()(unsigned
long)atomic
Patch 1 is Reviewed-by: Felix Kuehling
Patch 2: I'm not sure we need the "lock" parameter and the invalidation
engine parameter. If we're serious about consolidating TLB invalidation
between amdgpu and KFD, I think we should use the same invalidation
engine and the same lock. Then you also don't
On Mon, Oct 22, 2018 at 11:41 PM Michal Hocko wrote:
>
> On Mon 22-10-18 22:53:22, Arun KS wrote:
> > Remove managed_page_count_lock spinlock and instead use atomic
> > variables.
>
Hello Michal,
> I assume this has been auto-generated. If yes, it would be better to
> mention the script so that p
44 matches
Mail list logo