On 2019-02-19 4:09 p.m., Liu, Shaoyun wrote:
> When DPM for the specific clock is difabled, driver should still print out
> current clock info for rocm-smi support on vega20
>
> Change-Id: I8669c77bf153caa2cd63a575802eb58747151239
> Signed-off-by: shaoyunl
> ---
> drivers/gpu/drm/amd/powerplay/h
On 2019-02-19 1:48 p.m., Alex Deucher wrote:
> On Tue, Feb 19, 2019 at 1:47 PM Alex Deucher wrote:
>> On Tue, Feb 19, 2019 at 11:29 AM Zhao, Yong wrote:
>>> The original change caused regression, so revert it until the new fix is
>>> ready.
>>> https://bugs.freedesktop.org/show_bug.cgi?id=109650
[+Kent]
On 2019-02-19 12:08 p.m., Huang, JinHuiEric wrote:
> It seems redundant to print out all DPM levels when DPM is disabled.
> Probably it looks meaningful to print out "Mhz (DPM
> disabled)".
If you change the format, you risk breaking tools such as rocm-smi. Is
there some other way for ro
> default,
>>>>> which
>>>>> means if we drop this check, other devices may stop functioning
>>>>> unexpectedly?
>>>>>
>>>>> However, in the end I'd expect the kernel page allocation
>>>>> system
>>&
This is an RFC. I'm not sure this is the right solution, but it
highlights the problem I'm trying to solve.
The dma32_zone limits the acc_size of all allocated BOs to 2GB. On a
64-bit system with hundreds of GB of system memory and GPU memory,
this can become a bottle neck. We're seeing TTM memory
The series is Reviewed-by: Felix Kuehling
On 2019-02-14 6:45 p.m., Zhao, Yong wrote:
> The similar definitions should be consecutive.
>
> Change-Id: I936cf076363e641c60e0704d8405ae9493718e18
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 11 ++-
> 1 file ch
Please add a patch description.
It may make sense to define a first_non_cp doorbell index too. In patch
3 you have this, which is a bit inconsistent:
+ gpu_resources.non_cp_doorbells_start =
+ adev->doorbell_index.sdma_engine[0];
+ gpu_re
I pushed my patch series that simplifies eviction fence handling in KFD.
If you rebase this, it should be OK now.
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
> Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
> them during mapping.
>
> Signed-off-by: C
The series is Reviewed-by: Felix Kuehling
On 2019-02-07 5:23 p.m., Zhao, Yong wrote:
> They are no longer used, so delete them to avoid confusion.
>
> Change-Id: I3cf23fe7110ff88f53c0c279b2b4ec8d1a53b87c
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 8 --
Some nit-picks inline. Looks good otherwise.
On 2019-02-05 3:31 p.m., Zhao, Yong wrote:
> We can directly calculate the sdma doorbell index in the process doorbell
> pages through the doorbell_index structure in amdgpu_device, so no need
> to cache them in kgd2kfd_shared_resources any more, result
The code is fine. Some comments about your comment changes inline to
help clarify things a bit.
On 2019-02-05 3:31 p.m., Zhao, Yong wrote:
> Reserved doorbells for SDMA IH and VCN were not properly masked out
> when allocating doorbells for CP user queues. This patch fixed that.
>
> Change-Id: I6
Temporarily removing eviction fences to avoid triggering them by
accident is no longer necessary due to the fence_owner logic in
amdgpu_sync_resv.
As a result the ef_list usage of amdgpu_amdkfd_remove_eviction_fence
and amdgpu_amdkfd_add_eviction_fence are no longer needed.
Signed-off-by: Felix K
Use FENCE_OWNER_KFD to synchronize PT/PD initialization and clearing
of page table entries. This avoids triggering KFD eviction fences on
the PD reservation objects of compute VMs.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
Creates a temporary sync object to wait for the BO reservation. This
generalizes amdgpu_vm_wait_pd.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 24
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.
The fence_owner logic in amdgpu_sync_wait will allow waiting without
having to temporarily remove eviction fences.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
Sorry, I thought I had reviewed that already. The change is Reviewed-by: Felix
Kuehling
From: amd-gfx on behalf of Christian
König
Sent: Friday, February 8, 2019 7:42 AM
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: cleanup amdgpu_
Temporarily removing eviction fences to avoid triggering them by
accident is no longer necessary due to the fence_owner logic in
amdgpu_sync_resv.
As a result the ef_list usage of amdgpu_amdkfd_remove_eviction_fence
and amdgpu_amdkfd_add_eviction_fence are no longer needed.
Signed-off-by: Felix K
Use FENCE_OWNER_KFD to synchronize PT/PD initialization and clearing
of page table entries. This avoids triggering KFD eviction fences on
the PD reservation objects of compute VMs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
1 file changed, 3 insertions(+
Creates a temporary sync object to wait for the reservation. This
generalizes amdgpu_vm_wait_pd.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 25 +
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
The fence_owner logic in amdgpu_sync_wait will allow waiting without
having to temporarily remove eviction fences.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdg
06.02.19 um 00:51 schrieb Kuehling, Felix:
>> On 2019-02-05 11:00 a.m., Koenig, Christian wrote:
>>> Ah! The initial clear of the PDs is syncing to everything!
>> Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in
>> amdgpu_vm_clear_bo seems to help. But if I a
Reviewed-by: Felix Kuehling
From: amd-gfx on behalf of Christian
König
Sent: Thursday, February 7, 2019 5:43 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix NULL ptr dref in the VM code
The exclusive fence is of course perfectly o
Are you sure about this? Typically 64-bit doorbells don't wrap around. But this
one does. If the IH doorbell wraps around, there is no reason why it needs to
be 64-bit, so I suspect it may still be a 32-bit doorbell.
AFAIK, not all doorbells on Vega10 are 64-bit. It depends on the IP block.
The
;t synchronize with each other?
>
> Ok, that is easy to fix.
Not that easy. See above. ;)
Regards,
Felix
>
> Christian.
>
> Am 05.02.19 um 16:49 schrieb Kuehling, Felix:
>> I saw a backtrace from the GPU scheduler when I was debugging this
>> yester
The headline should start with "drm/amdgpu". This change is not KFD
specific.
I think Alex should review this change.
Regards,
Felix
On 2019-02-05 3:31 p.m., Zhao, Yong wrote:
> Indicate that the doorbell offset and range is in dwords.
>
> Change-Id: Ib0f2564ffa7b1940ffb8725cdc03f662184f5436
allocation that
synchronizes with the PD reservation object is a problem.
Regards,
Felix
-Original Message-
From: Christian König
Sent: Tuesday, February 05, 2019 10:40 AM
To: Kuehling, Felix ; Koenig, Christian
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM
ts for the fences on the PD reservation, which looks like an
eviction to KFD and triggers an unnecessary preemption. There is no actual
memory eviction happening here.
Regards,
Felix
-Original Message-
From: Christian König
Sent: Tuesday, February 05, 2019 6:37 AM
To: Kuehling, Felix ; am
On 2019-02-04 3:17 p.m., Kuehling, Felix wrote:
> This may cause regressions in KFD if PT BO allocation can trigger
> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
> context where we had temporarily removed the eviction fence. PT BO
> allocation in amdgpu_vm_bo_u
On 2019-02-04 7:42 a.m., Christian König wrote:
> No functional change.
>
> Signed-off-by: Christian König
Minor indentation issue inline. With that fixed, this patch is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
> 1 file changed, 8 in
On 2019-02-04 7:42 a.m., Christian König wrote:
> Otherwise we open up the possibility to use uninitialized memory.
>
> Signed-off-by: Christian König
This patch is Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 d
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into t
uted to CP. It is a must to program. We have to
> keep userqueue_start/end. Sorry for the confusion.
>
> Regards,
>
> Oak
>
> *From:* amd-gfx *On Behalf Of
> *Zhao, Yong
> *Sent:* Friday, February 1, 2019 7:04 PM
> *To:* Kuehling, Felix ;
> amd-gfx@lists.freedeskt
On 2019-01-31 5:27 p.m., Zhao, Yong wrote:
> Reserved doorbells for SDMA IH and VCN were not properly masked out
> when allocating doorbells for CP user queues. This patch fixed that.
>
> Change-Id: I670adfc3fd7725d2ed0bd9665cb7f69f8b9023c2
> Signed-off-by: Yong Zhao
One mostly cosmetic comment i
On 2019-02-01 8:23 a.m., Christian König wrote:
> Hi Felix,
>
> Am 31.01.19 um 22:38 schrieb Kuehling, Felix:
>> I don't see how this solves anything. You'll still need to remove
>> entries from this fault ring buffer. Otherwise you'll ignore faults for
>
On 2019-01-24 7:52 a.m., Christian König wrote:
> Remove the callback and call the dispatcher directly.
>
> Signed-off-by: Christian König
This patch is Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 4 +--
I don't see how this solves anything. You'll still need to remove
entries from this fault ring buffer. Otherwise you'll ignore faults for
addresses that have faulted recently, although it may be a new fault.
Also, this reintroduces interrupt storms and repeated processing of the
same fault in c
Thank you, Nathan. I applied your patch to amd-staging-drm-next.
Sorry for the late response. I'm catching up with my email backlog after
a vacation.
Regards,
Felix
On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: war
On 2019-01-21 4:55 a.m., Koenig, Christian wrote:
> Am 21.01.19 um 05:35 schrieb Liu, Monk:
>>
>> > Actually that's not so crazy at all. See the ATC uses the CPU page
>> tables to provide parts of the virtual GPU address space.
>>
>>
>>
>> So aperture 0->hole-start will be translated **not** by G
On 2019-01-14 5:01 a.m., Evan Quan wrote:
> + features_to_disable =
> + (features_enabled ^ new_ppfeature_masks) & features_enabled;
> + features_to_enable =
> + (features_enabled ^ new_ppfeature_masks) ^ features_to_disable;
This is confusing and unnecessarily com
The series is Reviewed-by: Felix Kuehling
-Original Message-
From: Christian König
Sent: Friday, January 11, 2019 7:02 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Kuehling, Felix
Subject: Re: [PATCH 1/3] drm/amdgpu: enable IH ring 1 and ring 2 v3
Am 09.01.19 um 14:12
The series is reviewed by me too.
Reviewed-by: Felix Kuehling
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Wednesday, January 09, 2019 10:06 AM
To: Russell, Kent ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/amdgpu: Add NBIO SMN headers v2
Series is:
Reviewed-by: Alex
dGPUs need their own topology devices. Don't assign them to APU topology
devices with CPU cores.
Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 12 +---
1 file changed, 9 insertions(+),
Thanks for this. I trust that your method for detecting that SMU or PSP
are running is correct. With that caveat the series is Reviewed-by:
Felix Kuehling
Regards,
Felix
On 2019-01-08 5:11 p.m., Alex Deucher wrote:
> Fixes for kexec. The GPU needs to be reset before the driver
> can be loaded
I'm not saying it's useless. But rocm-smi can already get the clocks
from sysfs (pp_dpm_sclk and pp_dpm_mclk). Are these clocks any different?
Regards,
Felix
On 2019-01-08 4:32 p.m., Deucher, Alexander wrote:
>
> Ping? Useful for rocm-smi?
>
>
On 2019-01-08 6:28 a.m., Russell, Kent wrote:
> Add a sysfs file that reports the number of bytes transmitted and
> received in the last second. This can be used to approximate the PCIe
> bandwidth usage over the last second.
>
> v2: Clarify use of mps as estimation of bandwidth
I think you only
ifdef x86_64 specific code.
Allow enabling CONFIG_HSA_AMD on ARM64.
v2: Fixed a compiler warning due to an unused variable
CC: Mark Nutter
Signed-off-by: Felix Kuehling
Acked-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdkfd/Kconfig| 4 ++--
drivers/gpu/drm/am
On 2019-01-04 7:35 a.m., Russell, Kent wrote:
> Add a sysfs file that reports the number of bytes transmitted and
> received in the last second. This can be used to approximate the PCIe
> bandwidth usage over the last second.
>
> Change-Id: I6c82fe1cb17726825736512990fa64f5c1489861
> Signed-off-by:
On 2019-01-03 12:34 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expressions by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: c8c5e569c5b0 ("drm/amdgpu: Consolidate visible vs. real vram check
> v2.")
Actual
On 2019-01-03 4:59 a.m., Christian König wrote:
> Otherwise we run into a non-retry fault on access.
>
> It seems to be a hardware bug that the executable bit has
> higher priority than the valid bit.
>
> v2: handle clears as well
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amd
ifdef x86_64 specific code.
Allow enabling CONFIG_HSA_AMD on ARM64.
CC: Mark Nutter
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/Kconfig| 4 ++--
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 8
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 8 +---
3 files chang
Don't you need to update amdgpu_vm_clear_freed as well?
Regards,
Felix
On 2019-01-02 8:35 a.m., Christian König wrote:
> Otherwise we run into a non-retry fault on access.
>
> It seems to be a hardware bug that the executable bit has
> higher priority than the valid bit.
>
> Signed-off-by: Chri
Except for the GEM and CS parts, the series is Reviewed-by: Felix
Kuehling
Regards,
Felix
On 2018-12-14 4:10 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
> hmm_vma_rang
The series is Reviewed-by: Felix Kuehling
On 2018-12-14 10:22 a.m., Lin, Amber wrote:
> Since amdkfd is merged into amdgpu module and amdgpu can access amdkfd
> directly, move declaration of kgd2kfd functions from kfd_priv.h to
> amdgpu_amdkfd.h
>
> Signed-off-by: Amber Lin
> ---
> drivers/gpu/
On 2018-12-14 2:31 p.m., Wentland, Harry wrote:
> On 2018-12-07 3:32 p.m., Kuehling, Felix wrote:
>> 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:
>>>
Looks good for the KFD part. One nit-pick inline. And two more
suggestions about amdgpu_ttm.c to make our handling of
get_user_pages_done more robust.
Christian, would you review the CS and GEM parts? And maybe take a look
you see nothing wrong with the amdgpu_ttm changes either.
On 2018-12-13 4:
On errors, dma_buf_get returns a negative error code, rather than NULL.
Reported-by: Dan Carpenter
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drive
Reviewed-by: Felix Kuehling
Thanks,
Felix
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, December 13, 2018 9:59:30 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix; Quan, Evan
Subject: [PATCH] drm/amdgpu: update the vm invalidation
Some nit-picks inline.
On 2018-12-12 11:09 p.m., Evan Quan wrote:
> We need new invalidation engine layout due to new SDMA page
> queues added.
>
> Change-Id: I2f3861689bffb9828c9eae744a7a0de4963ac2b6
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 47 ++---
This is a nice improvement from the last version. I still see some
potential problems. See inline ...
I'm skipping over the CS and GEM parts. I hope Christian can review
those parts.
On 2018-12-06 4:02 p.m., Yang, Philip wrote:
> Use HMM helper function hmm_vma_fault() to get physical pages backi
This function was renamed in a previous commit. Update the stub
function name for builds with CONFIG_HSA_AMD disabled.
Fixes: 62f65d3cb34a ("drm/amdgpu: Add KFD VRAM limit checking")
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
1 file changed, 1 insertion(
gt; StDenis, Tom
> *Sent:* December 10, 2018 10:02 AM
> *To:* Kuehling, Felix
> *Cc:* Huang, JinHuiEric; Deucher, Alexander; amd-gfx mailing list
> *Subject:* amdkfd build regression if HSA_AMD is disabled
>
> Hi All,
>
> The commit:
>
> commit 62f65d3cb34a830
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
>
> ----
>
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
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/
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 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:
>>>
>>>
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-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
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-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/
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
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
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
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
>>
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
>
_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,
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
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
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
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 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
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 |
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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
401 - 500 of 558 matches
Mail list logo
