On 2019-09-26 5:59 p.m., Zhao, Yong wrote:
> On 2019-09-26 5:36 p.m., Kuehling, Felix wrote:
>> Minor nit-pick inline. Otherwise this patch is
>>
>> Reviewed-by: Felix Kuehling
>>
>> On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
>>> This makes possible the
For GFXv9 you made an equivalent change for both GFXHub and MMHub
("drm/amdgpu: Expose *_setup_vm_pt_regs for kfd to use"). Your GFXv9
commit was also reviewed by Alex and Christian. You should get at least
one of them to Ack or Review this change.
For GFXv10 you're only changing the GFXHub. I
On 2019-09-25 2:15 p.m., Zhao, Yong wrote:
> This was done on GFX9 previously, now do it for GFX10.
>
> Change-Id: I4442e60534c59bc9526a673559f018ba8058deac
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 23 +++
>
On 2019-09-27 0:33, Liang, Prike wrote:
> The patch c670707 drm/amd: Pass drm_device to kfd introduced this issue and
> fix the following compiler error.
>
>CC [M] drivers/gpu/drm/amd/amdgpu//../powerplay/smumgr/fiji_smumgr.o
> drivers/gpu/drm/amd/amdgpu//amdgpu_amdkfd.c:746:6: error: conflict
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> This is the same idea as the kfd device info probe and move all the
> probe control together for easy maintenance.
>
> Change-Id: I85c98bb08eb2a4a1a80c3b913c32691cc74602d1
> Signed-off-by: Yong Zhao
Nice clean-up. See one comment inline.
Also, please
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> The code use hex define, so should the printing. Also, printf a message
> if there is a failure.
>
> Change-Id: Ia7cc7690553bb043915b3d8c0157216c64421a60
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +++--
> 1 file
If you want to make this interface consistent, you should make the vmid
parameter uint8_t at the same time. That said, you don't really save any
resources, because 8-bit and 16-bit ints still consume 32-bits on the
call stack.
Regards,
Felix
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> Thi
As far as I can tell, this is the only patch with functional changes in
the patch series. The rest are purely clean-up. Any relation I'm missing?
Anyway, patches 2,3,5 are
Reviewed-by: Felix Kuehling
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> The HDP flush support code was missing in the nb
On 2019-09-30 17:55, Zhao, Yong wrote:
> The code use hex define, so should the printing.
>
> Change-Id: Ia7cc7690553bb043915b3d8c0157216c64421a60
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +++--
> 1 file changed, 3 insertion
Don't set a struct pointer to NULL before freeing its members. It's
hard to see what's happening due to a local pointer-to-pointer data
aliasing con->eh_data.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On 2019-10-04 10:48, Zeng, Oak wrote:
> On device initialization, a trunk of GTT memory is pre-allocated for
> HIQ and all SDMA queues mqd. The size of this allocation was wrong.
> The correct sdma engine number should be PCIe-optimized SDMA engine
> number plus xgmi SDMA engine number.
>
> Change-
On 2019-10-04 10:48, Zeng, Oak wrote:
> Previously only PCIe-optimized SDMA engine hqds were
> exposed in debug fs. Print all SDMA engine hqds.
>
> Change-Id: I03756fc0fa99169d88e265560f505ed186242b02
> Reported-by: Jonathan Kim
> Signed-off-by: Jonathan Kim
> Signed-off-by: Oak Zeng
Minor cosme
uld
go in gmc_v9_0_hw_init.
Regards,
Felix
On 2019-10-04 10:56, Zeng, Oak wrote:
> Ping...
>
> Regards,
> Oak
>
> -Original Message-
> From: Zeng, Oak
> Sent: Thursday, September 19, 2019 5:17 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Koe
On 2019-10-07 12:08 p.m., Alex Deucher wrote:
> On Sat, Oct 5, 2019 at 1:58 PM Colin King wrote:
>> From: Colin Ian King
>>
>> Function kgd2kfd_init is missing a void argument, add it
>> to clean up the non-ANSI function declaration.
>>
>> Signed-off-by: Colin Ian King
> Applied. thanks!
Thank
On 2019-10-04 10:15 a.m., Alex Deucher wrote:
> Add proper ifdefs around CIK code in kfd setup.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Felix Kuehling
Thanks!
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/
On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> drm.lgpu
> A read-write nested-keyed file which exists on all cgroups.
> Each entry is keyed by the DRM device's major:minor.
>
> lgpu stands for logical GPU, it is an abstraction used to
> subdivide a physical DRM devic
On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> The number of logical gpu (lgpu) is defined to be the number of compute
> unit (CU) for a device. The lgpu allocation limit only applies to
> compute workload for the moment (enforced via kfd queue creation.) Any
> cu_mask update is validated against the
On 2019-10-09 6:31, Daniel Vetter wrote:
> On Tue, Oct 08, 2019 at 06:53:18PM +0000, Kuehling, Felix wrote:
>>
>> The description sounds reasonable to me and maps well to the CU masking
>> feature in our GPUs.
>>
>> It would also allow us to do more coar
On 2019-10-09 11:34, Daniel Vetter wrote:
> On Wed, Oct 09, 2019 at 03:25:22PM +0000, Kuehling, Felix wrote:
>> On 2019-10-09 6:31, Daniel Vetter wrote:
>>> On Tue, Oct 08, 2019 at 06:53:18PM +0000, Kuehling, Felix wrote:
>>>> The description sounds reasonable to me a
On 2019-10-11 10:36 a.m., Yang, Philip wrote:
> user_pages array should always be freed after validation regardless if
> user pages are changed after bo is created because with HMM change parse
> bo always allocate user pages array to get user pages for userptr bo.
>
> v2: remove unused local varia
[AMD Official Use Only - Internal Distribution Only]
[Dropping most, +Alex, +Xinhui]
Looks like this was introduced by Xinhui's change:
commit be8e48e0849943fb53457e2fd83905eaf19cb1f7
Author: xinhui pan
Date: Tue Feb 11 11:28:34 2020 +0800
drm/amdgpu: Remove kfd eviction fence before rele
[AMD Official Use Only - Internal Distribution Only]
I pushed the fix to amd-staging-drm-next. How do we get this into linux-next?
-Original Message-
From: Kuehling, Felix
Sent: Wednesday, February 26, 2020 11:11
To: Pan, Xinhui ; Deucher, Alexander
(alexander.deuc...@amd.com)
Cc: amd
| \ / | | _ \ \ _ |
/ A \ | \M/ | | |D) ) /|_| |
/_/ \_\ |_| |_| |_/ |__/ \| facebook.com/AMD | amd.com
From: Zhang, Jerry
Sent: Tuesday, March 28, 2017 10:54:03 PM
To: Kuehling, Felix; amd-gfx@lists.freedesktop.org; Koenig, Christian; Zhou,
David(Ch
ucher, Alexander
Sent: Monday, August 08, 2016 2:04 PM
To: StDenis, Tom; Kuehling, Felix; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 09/14] drm/amd/amdgpu: Enable carrizo GFX PG
I'm not sure gfx PG works properly with some of the kfd features. I know there
were problems in the past. We probab
, 2022 11:21 PM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Cc: Phillips, Daniel ; Ji, Ruili ;
Liu, Aaron
Subject: RE: [PATCH] drm/amdkfd: Remove Align VRAM allocations to 1MB on APU
ASIC
[AMD Official Use Only - General]
Thanks Felix comment, I will further debug this issue
egards,
Felix
-Original Message-
From: Huang, JinHuiEric
Sent: Thursday, April 27, 2023 14:58
To: Kuehling, Felix ; Koenig, Christian
; Christian König ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Ignore KFD eviction fences invalidating
preemptible DMABuf imports
Hi
bo_va->base.moved
= false (it's done a few lines above this under some conditions, but not
always). The new code will always set bo_va->base.moved = false inside
amdgpu_vm_bo_idle.
Regards,
Felix
From: Christian König
Sent: Saturday, Septe
This is on purpose. These functions for now are place holders because the PSP
firmware interface is not ready yet, and we want to start testing XGMI with
higher level code with some hard-coded topology. Once we have proper PSP
firmware, these place holders will be filled in.
Regards,
Felix
_
ore challenging and
less effective.
Regards,
Felix
From: Christian König
Sent: Tuesday, September 11, 2018 2:49:44 AM
To: Kuehling, Felix; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 01/11] drm/amdgpu: try allocating VRAM as power of two
Yeah well
least for currently available hardware we should limit page faults to
> be used in as few cases as possible, e.g. SVM and userptr.
>
> Regards,
> Christian.
From: Koenig, Christian
Sent: Wednesday, September 12, 2018 11:59 AM
To: Kuehling, Fe
: Kuehling, Felix ; Yang, Philip
; amd-gfx@lists.freedesktop.org; Jerome Glisse
Subject: Re: [PATCH] drm/amdgpu: use HMM mirror callback to replace mmu
notifier v4
Am 14.09.2018 um 22:21 schrieb Felix Kuehling:
> On 2018-09-14 01:52 PM, Christian König wrote:
>> Am 14.09.2018 um 19:47 schri
eeds to update the userptr addresses. If
the page tables are still being updated, it will block there even without
holding the amdgpu_mn_read_lock.
Regards,
Felix
From: Koenig, Christian
Sent: Thursday, September 27, 2018 3:00 AM
To: Kuehling, Felix
Cc: Yang, Philip ; amd-gfx@lists.freedesktop.
e.
I don’t see why this requires holding the read-lock until invalidate_range_end.
amdgpu_ttm_tt_affect_userptr gets called while the mn read-lock is held in
invalidate_range_start notifier.
Regards,
Felix
From: Koenig, Christian
Sent: Thursday, September 27, 2018 5:27 AM
To: Kuehling, Felix
Cc:
bles just in the moment
> between the check of amdgpu_ttm_tt_userptr_needs_pages() and adding the fence
> to the reservation object.
I’m not planning to change that. I don’t think there is any need to change it.
Regards,
Felix
From: Koenig, Christian
Sent: Thursday, September 27, 2018 7
hole argument is that you don’t need to hold the read lock until the
invalidate_range_end. Just read_lock and read_unlock in the
invalidate_range_start function.
Regards,
Felix
From: Koenig, Christian
Sent: Thursday, September 27, 2018 9:22 AM
To: Kuehling, Felix
Cc: Yang, Philip ; amd-gf
er 27, 2018 9:59 AM
To: Kuehling, Felix
Cc: Yang, Philip ; amd-gfx@lists.freedesktop.org; Jerome
Glisse
Subject: RE: [PATCH] drm/amdgpu: use HMM mirror callback to replace mmu
notifier v4
Yeah I understand that, but again that won't work.
In this case you can end up accessing pages which
I think the answer is here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/vm/hmm.rst#n216
Regards,
Felix
From: Koenig, Christian
Sent: Thursday, September 27, 2018 10:30 AM
To: Kuehling, Felix
Cc: j.gli...@gmail.com; Yang, Philip ;
amd-gfx
Hi Alex,
If it's not too late, I'd like to get this into 4.19. Sorry I missed this fix
earlier.
Regards,
Felix
____
From: Kuehling, Felix
Sent: Tuesday, October 2, 2018 6:41:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: oded.gab...@gmail.com; Kuehl
On 2018-10-18 6:03 p.m., Deucher, Alexander wrote:
>
> Series is:
>
> Reviewed-by: Alex Deucher
>
Reviewed-by: Felix Kuehling
as well.
>
> *From:* amd-gfx on behalf of
> Lin, Amber
> *Sent:* Thursday, October 18, 2018
On 2018-10-18 5:59 p.m., wrote:
>
> Please include a patch description on 2 and 3, with that fixed, series is:
>
> Reviewed-by: Alex Deucher
>
Reviewed-by: Felix Kuehling
>
> *From:* Zhao, Yong
> *Sent:* Thursday, October
[+Christian]
Should the buffer funcs also use the paging ring? I think that would be
important for being able to clear page tables or migrating a BO while
handling a page fault.
Regards,
Felix
On 2018-10-19 3:13 p.m., Yang, Philip wrote:
> For sdma v4, there is bug caused by
> commit d4e869b6b
On 2018-10-19 11:15 a.m., Lin, Amber wrote:
> Add amdgpu_amdkfd_ prefix to amdgpu functions served for amdkfd usage.
>
> v2: fix indentation
>
> Signed-off-by: Amber Lin
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 18 +-
> drivers/gpu/
The BIOS signature check does not guarantee integrity of the BIOS image
either way. As I understand it, the signature is just a magic number.
It's not a cryptographic signature. The check is just a sanity check.
Therefore this change doesn't add any meaningful protection against the
scenario you de
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
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
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
On 2018-10-25 10:38 a.m., Christian König wrote:
> Make sure we don't try to go down further after the leave walk already
> ended. This fixes a crash with a new VM test.
>
> Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
Regards,
Felix
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_v
On 2018-10-25 2:27 p.m., Alex Deucher wrote:
> On Mon, Oct 22, 2018 at 6:25 PM Alex Deucher wrote:
>> Use the appropriate mmhub and gfxhub headers rather than adding
>> them to the gmc9 header.
>>
>> Signed-off-by: Alex Deucher
> Ping?
Reviewed-by: Felix Kuehling
>
> Alex
>
>> ---
>> drivers
On 2018-11-02 9:48 a.m., Christian König wrote:
> Vega10 has multiple interrupt rings,
I don't think I've seen your code that implements multiple interrupt
rings. So it's a bit hard to comment. As I understand it, the only way
this could happen is, if the two interrupt rings are handled by
differe
On 2018-11-04 2:20 p.m., Christian König wrote:
> Am 02.11.18 um 19:59 schrieb Kuehling, Felix:
>> On 2018-11-02 9:48 a.m., Christian König wrote:
>>> Vega10 has multiple interrupt rings,
>> I don't think I've seen your code that implements multiple interru
These are some recent patches that are easy to upstream (part 1). For
part 2 (hopefully still this month) I'll need to advance the merging
of KFD into amdgpu a little further to avoid upstreaming duplicated
data structures that no longer need to be duplicated.
Eric Huang (1):
drm/amdkfd: change
From: Yong Zhao
This will make reading code much easier. This fixes a few spots missed in a
previous commit with the same title.
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 12 ++--
1 f
The adev parameter in amdgpu_sync_fence and amdgpu_sync_resv is only
needed for updating sync->last_vm_update. This breaks if different
adevs are passed to calls for the same sync object.
Always pass NULL for calls from KFD because sync objects used for
KFD don't belong to any particular device, a
From: Harish Kasiviswanathan
PD or PT might have to be moved during validation and this move has to be
completed before updating it. If page table updates are done using SDMA
then this serializing is done by SDMA command submission.
And if PD/PT updates are done by CPU, then explicit waiting for
From: Harish Kasiviswanathan
Instead of waiting for each KFD BO after validation just wait for the
last BO moving fence.
Signed-off-by: Harish Kasiviswanathan
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 -
1
From: Gang Ba
Add Vega12 and Polaris12 device info and device IDs to KFD.
Signed-off-by: Gang Ba
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +-
drivers/gpu/dr
From: Yong Zhao
This makes debug message get printed even when there is early return.
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
d
This change prepares for adding SG BOs that will be used for mapping
doorbells into GPUVM address space.
This type of BO would be mistaken for an invalid userptr BO. Improve
that check to test that it's actually a userptr BO so that SG BOs that
are still in the CPU domain can be validated and mapp
From: Yong Zhao
This is a known gfx9 HW issue, and this change can perfectly workaround
the issue.
Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 25 ++---
1 file changed, 22 inserti
From: Eric Huang
It is to improve system limit by:
1. replacing userptrlimit with a total memory limit that
conunts TTM memory usage and userptr usage.
2. counting acc size for all BOs.
Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/am
[+Philip]
On 2018-11-07 12:25 a.m., Zhang, Jerry(Junwei) wrote:
> On 11/7/18 1:15 PM, Trigger Huang wrote:
>> Currently, SDMA page queue is not used under SR-IOV VF, and this
>> queue will
>> cause ring test failure in amdgpu module reload case. So just disable
>> it.
>>
>> Signed-off-by: Trigger
On 2018-11-12 12:09 p.m., Christian König wrote:
> We accidentially set the huge flag on the parent instead of the childs.
> This caused some VM faults under memory pressure.
Reviewed-by: Felix Kuehling
I got a bit confused when re-reading this code. Maybe part of it is that
cursor.entry is not
This change is not suitable for amd-staging-drm-next. PCIe P2P was not enabled
on amd-staging-drm-next because it's not reliable yet. This change enables it
even in situations that are not safe (including small BAR systems).
Why are you porting this change to amd-staging-drm-next? Does anyone de
You changed the doorbell routing in NBIO. I think that won't work for SR-IOV,
because it's not controlled by the guest OS there. We may need to disable
paging queue doorbell on Vega10 and Vega12 with SRIOV. For Vega20 we plan to
change the doorbell layout before it goes to production (Oak starte
, Kent
Sent: Thursday, November 15, 2018 1:04 PM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: Re: [PATCH] drm/amdgpu : Use XGMI mapping when devices on the same
hive v2
It was merged to 4.19 on Sept 21. It got missed on the 4.20 rebase.
Kent
KENT RUSSELL
Sr
Sorry, something is still missing here. The new variable vram_base_offset isn't
used anywhere. We have some other changes in amd-kfd-staging to use that
vram_base_offset that are probably missing on amd-staging-drm-next. This change
won't have any effect as is.
Regards,
Felix
-Original M
Apologies. We already have a fix for this on our internal amd-kfd-staging
branch, but it's missing from amd-staging-drm-next. I'll cherry-pick our fix to
amd-staging-drm-next and nominate it for drm-fixes.
Regards,
Felix
-Original Message-
From: amd-gfx On Behalf Of Joerg Roedel
Sent
On Vega20 and other pre-production GPUs, powerplay is not enabled yet.
Check for NULL pointers before calling pp_funcs function pointers.
Also affects Kaveri.
CC: Joerg Roedel
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +--
1 file changed, 5 insertions
Looks good to me. Reviewed-by: Felix Kuehling
I hope Alex or Christian can also review this in case I'm missing
something about how doorbells are used in amdgpu.
Regards,
Felix
On 2018-11-16 2:08 p.m., Yang, Philip wrote:
> Because increase SDMA_DOORBELL_RANGE to add new SDMA doorbell for pag
OK with
this I'll go ahead and push this upstream as well.
Thanks,
Felix
On 2018-11-05 8:40 p.m., Kuehling, Felix wrote:
> The adev parameter in amdgpu_sync_fence and amdgpu_sync_resv is only
> needed for updating sync->last_vm_update. This breaks if different
> adevs are pas
On 2018-11-16 3:30 p.m., Alex Deucher wrote:
> Looks like a copy paste typo.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
On 2018-11-16 4:35 p.m., Alex Deucher wrote:
>> + ring->doorbell_index += 0x400;
> I don't quite understand how this works. Why don't we have to adjust
> the doorbell range registers in the nbio code?
NBIO only looks at the lower 12 bits of the doorbell address. So adding
0
lex Deucher
>
>
> *From:* amd-gfx on behalf of
> Kuehling, Felix
> *Sent:* Thursday, November 15, 2018 4:56:51 PM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Kuehling, Felix; Joerg Roedel
> *Subject:* [PATCH] drm/amdgpu: Fix oops when
> p
Hi Christian,
On 2018-11-19 6:24 a.m., Christian König wrote:
> Am 15.11.18 um 20:10 schrieb Yang, Philip:
>> paging queues doorbell index use existing assignment
>> sDMA_HI_PRI_ENGINE0/1
>> index, and increase SDMA_DOORBELL_RANGE size from 2 dwords to 4
>> dwords to
>> enable the new doorbell ind
top_dev->gpu is NULL for CPUs. Avoid dereferencing it if NULL.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
in
This round adds support for more ROCm memory manager features:
* VRAM limit checking to avoid overcommitment
* DMABuf import for graphics interoperability
* Support for mapping doorbells into GPUVM address space
Felix Kuehling (4):
drm/amdgpu: Add KFD VRAM limit checking
drm/amdkfd: Add NULL-p
This is used for interoperability between ROCm compute and graphics
APIs. It allows importing graphics driver BOs into the ROCm SVM
address space for zero-copy GPU access.
The API is split into two steps (query and import) to allow user mode
to manage the virtual address space allocation for the i
We don't want KFD processes evicting each other over VRAM usage.
Therefore prevent overcommitting VRAM among KFD applications with
a per-GPU limit. Also leave enough room for page tables on top
of the application memory usage.
Signed-off-by: Felix Kuehling
Reviewed-by: Eric Huang
---
drivers/gp
This allows user mode to map doorbell pages into GPUVM address space.
That way GPUs can submit to user mode queues (self-dispatch).
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 59 ++--
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |
On 2018-11-22 12:03 p.m., Liu, Shaoyun wrote:
> Driver shouldn't try to access any GFX registers until RLC is idle.
> During the test, it took 12 seconds for RLC to clear the BUSY bit
> in RLC_GPM_STAT register which is un-acceptable for driver.
> As per RLC engineer, it would take RLC Ucode less t
On 2018-10-22 1:23 p.m., Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
>
> Suggested-by: Michal Hocko
> Suggested-by: Vlastimil Babka
> Signed-off-by: Arun KS
Acked-by: Felix Kuehling
Regards,
Felix
>
> ---
> As discussed here,
> https://patch
On 2018-11-22 1:22 p.m., Liu, Shaoyun wrote:
> Driver shouldn't try to access any GFX registers until RLC is idle.
> During the test, it took 12 seconds for RLC to clear the BUSY bit
> in RLC_GPM_STAT register which is un-acceptable for driver.
> As per RLC engineer, it would take RLC Ucode less th
Don't bounce back to the root level for fragment processing, because
huge pages are not supported at that level. This is unlikely to happen
with the default VM size on Vega, but can be exposed by limiting the
VM size with the amdgpu.vm_size module parameter.
Signed-off-by: Felix Kuehling
---
dri
Avoid potential integer overflows with left shift in huge-page mapping
code by casting the operand to uin64_t first.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
Won't this break VM fault handling in KFD? I don't see a way with the current
code that you can leave some VM faults for KFD to process. If we could consider
VM faults with VMIDs 8-15 as not handled in amdgpu and leave them for KFD to
process, then this could work.
As far as I can tell, the onl
_CP_BAD_OPCODE_ERROR (183)
GFX_9_0__SRCID__SQ_INTERRUPT_ID (239)
239 is used for signaling events from shaders and can be very frequent.
Triggering an error message on those interrupts would be bad.
Regards,
Felix
>
> Regards,
> Christian.
>
> Am 30.11.18 um 17:31 schrieb Kuehling,
Shaoyun, FYI
Acked-by: Felix Kuehling
On 2018-12-03 3:28 p.m., Deucher, Alexander wrote:
>
> Acked-by: Alex Deucher
>
>
> *From:* amd-gfx on behalf of
> Andrey Grodzovsky
> *Sent:* Monday, December 3, 2018 3:03:41 PM
>
On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> Quoting Ho, Kenny (2018-11-27 17:41:17)
>> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
>> wrote:
>>> I think a more abstract property "% of GPU (processing power)" might
>>> be a more universal approach. One can then implement that through
>>
Ping. Any comments, R-b, A-b?
On 2018-11-20 10:07 p.m., Kuehling, Felix wrote:
> This round adds support for more ROCm memory manager features:
> * VRAM limit checking to avoid overcommitment
> * DMABuf import for graphics interoperability
> * Support for mapping doorbells into G
See comments inline. I didn't review the amdgpu_cs and amdgpu_gem parts
as I don't know them very well.
On 2018-12-03 3:19 p.m., Yang, Philip wrote:
> Use HMM helper function hmm_vma_fault() to get physical pages backing
> userptr and start CPU page table update track of those pages. Then use
> hm
Depending on the interrupt ring, the IRQ dispatch and processing
functions will run in interrupt context or in a worker thread.
Is there a way for the processing functions to find out which context
it's running in? That may influence decisions whether to process
interrupts in the same thread or sc
On 2018-12-05 4:15 a.m., Christian König wrote:
> This finally enables processing of ring 1 & 2.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 68 --
> 1 file changed, 63 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/
Patches 1-3 are Reviewed-by: Felix Kuehling
I applied all 10 patches and tested them with kfdtest on Fiji and
Vega10. It seems to not break anything obvious.
I think I found a problem in patch 9 and have a question about patch 8
regarding the context in which interrupt processing functions would
On 2018-12-06 6:32 a.m., Rex Zhu wrote:
> used to manager the reserverd vm space.
>
> Signed-off-by: Rex Zhu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 8 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 4 +++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> 3 files changed, 1
This change seems to be breaking the build for me. I'm getting errors like this:
CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o
In file included from ../include/trace/events/tlb.h:9:0,
from ../arch/x86/include/asm/mmu_context.h:10,
from ../i
On 2018-12-07 9:46 a.m., Wentland, Harry wrote:
> On 2018-12-07 9:41 a.m., Wentland, Harry wrote:
>> On 2018-12-07 12:40 a.m., Kuehling, Felix wrote:
>>> This change seems to be breaking the build for me. I'm getting errors like
>>> this:
>>>
>>>
Can you add them amdkfd/kfd_device.c as well while you're at it.
Thanks,
Felix
On 2018-12-07 4:03 p.m., Alex Deucher wrote:
> New vega ids.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++
> 1 file changed, 6 insertions(+
On 2018-12-07 4:26 p.m., Alex Deucher wrote:
> New vega10 ids.
>
> Signed-off-by: Alex Deucher
The series is Reviewed-by: Felix Kuehling
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/
Avoid including mmu_context.h in amdgpu_amdkfd.h since that may be
included in other header files that define traces. This leads to
conflicts due to traces defined in other headers included via
mmu_context.h.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1
Thanks. I see you added the KFD change in a separate patch series.
This one is also Reviewed-by: Felix Kuehling
On 2018-12-07 4:16 p.m., Deucher, Alexander wrote:
>
> Will do.
>
>
> Alex
>
> ----
>
101 - 200 of 558 matches
Mail list logo
