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
, 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
memory eviction.
Regards,
Felix
From: Koenig, Christian
Sent: Wednesday, April 15, 2020 6:58 AM
To: Kim, Jonathan ; Kuehling, Felix
; Deucher, Alexander
Cc: Russell, Kent ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Revert "drm/amdgpu: use th
riginal Message-
From: Lin, Amber
Sent: Friday, April 3, 2020 11:38
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amdkfd: Provide SMI events watch
Further thinking about it, I'll use struct kfd_smi_msg_header. Instead of using
struct kfd_smi_msg_vmfault
[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
[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
Are you sure that setting the SQ_SHADER_TBA_HI__TRAP_EN bit on GFXv9 is
completely harmless? If the field is not defined, maybe setting the bit
makes the address invalid. It's probably worth running that through a
PSDB, which would cover Vega10, Vega20 and Arcturus.
If it actually works, the pa
On 2019-11-07 13:32, Alex Deucher wrote:
> On Thu, Nov 7, 2019 at 12:47 PM Kuehling, Felix
> wrote:
>> No, please lets not add a new nomenclature for PM4 packet versions. GFX
>> versions are agreed on between hardware, firmware, and software and it's
>> generally
eel terribly strongly about.
With that said, the change is
Reviewed-by: Felix Kuehling
<mailto:felix.kuehl...@amd.com>
Regards,
Felix
Regards,
Yong
From: Kuehling, Felix <mailto:felix.kuehl...@amd.com>
Sent: Thursday, November 7, 2019 2
x Deucher <mailto:alexdeuc...@gmail.com>
Sent: Thursday, November 7, 2019 1:32 PM
To: Kuehling, Felix <mailto:felix.kuehl...@amd.com>
Cc: Zhao, Yong <mailto:yong.z...@amd.com>; Russell, Kent
<mailto:kent.russ...@amd.com>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@list
On 2019-11-07 12:33, Zhao, Yong wrote:
> The new code uses straightforward bit shifts and thus has better readability.
>
> Change-Id: I0c1f7cca7e24ddb7b4ffe1cb0fa71943828ae373
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 17 +++
<mailto:amd-gfx-boun...@lists.freedesktop.org>
On Behalf Of Zhao, Yong
Sent: Thursday, November 7, 2019 11:57 AM
To: Kuehling, Felix <mailto:felix.kuehl...@amd.com>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] drm/amdkfd: only ke
On 2019-11-05 18:18, Zhao, Yong wrote:
> The new code uses straightforward bit shifts and thus has better
> readability.
You're missing the MMAP-related code for mmio remapping. In
kfd_ioctl_alloc_memory_of_gpu:
/* MMIO is mapped through kfd device
* Generate a kfd mmap offse
On 2019-10-30 20:17, Zhao, Yong wrote:
> The kernel queue functions for v9 and v10 are the same except
> pm_map_process_v* which have small difference, so they should be reused.
> This eliminates the need of reapplying several patches which were
> applied on v9 but not on v10, such as bigger GWS an
On 2019-10-30 20:17, Zhao, Yong wrote:
> release_mem won't be used at all on GFX9 and GFX10, so delete it.
Hawaii was GFXv7. So we're not using the release_mem packet on GFXv8
either. Why arbitrarily limit this change to GFXv9 and 10?
Regards,
Felix
>
> Change-Id: I13787a8a29b83e7516c582a740
On 2019-10-30 20:17, Zhao, Yong wrote:
> This is cleaner.
>
> Change-Id: I8cdecad387d8c547a088c6050f77385ee1135be1
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> .../gpu/drm/amd/amdkfd/kfd_kernel_queue_v9.c | 19 +++
> 1 file changed, 7 insertions(+), 12 deleti
On 2019-11-05 5:26 p.m., Huang, JinHuiEric wrote:
> Using unified VBIOS has performance drop in sriov environment.
> The fix is switching to another register instead.
>
> Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Acked-by: Oded Gabbay
Signed-off-by: Oded Gabbay
Regards,
Felix
>
> Regards,
> Yong
> ----
> *From:* Kuehling, Felix
> *Sent:*
On 2019-11-05 5:03 p.m., Huang, JinHuiEric wrote:
> Using unified VBIOS has performance drop in sriov environment.
> The fix is switching to another register instead.
>
> Signed-off-by: Eric Huang
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 18 +++---
> 1 file changed, 15 inser
On 2019-11-01 4:48 p.m., Zhao, Yong wrote:
> The new code is much cleaner and results in better readability.
>
> Change-Id: I0c1f7cca7e24ddb7b4ffe1cb0fa71943828ae373
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 13 +++--
> drivers/gpu/drm/amd/amdkfd/kfd_
NAK. This won't work for several reasons.
The mmap_offset is used as offset parameter in the mmap system call. If
you check the man page of mmap, you'll see that "offset must be a
multiple of the page size". Therefore the PAGE_SHIFT is necessary.
In the case of doorbell offsets, the offset is p
On 2019-10-30 9:52 a.m., Christian König wrote:
> Am 29.10.19 um 21:06 schrieb Huang, JinHuiEric:
>> The issue is PT BOs are not freed when unmapping VA,
>> which causes vram usage accumulated is huge in some
>> memory stress test, such as kfd big buffer stress test.
>> Function amdgpu_vm_bo_update
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Remove the interval tree in the driver and rely on the tree maintained by
> the mmu_notifier for delivering mmu_notifier invalidation callbacks.
>
> For some reason amdgpu has a very complicated arrangement where it tries
I haven't had enough time to fully understand the deferred logic in this
change. I spotted one problem, see comments inline.
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Of the 13 users of mmu_notifiers, 8 of them use only
> invalidate_range_start/end() and immedia
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> find_vma() must be called under the mmap_sem, reorganize this code to
> do the vma check after entering the lock.
>
> Further, fix the unlocked use of struct task_struct's mm, instead use
> the mm from hmm_mirror which has
On 2019-10-24 5:14 p.m., Zhao, Yong wrote:
> The KIQ is on the second MEC and its reservation is covered in the
> latter logic, so no need to reserve its bit twice.
>
> Change-Id: Ieee390953a60c7d43de5a9aec38803f1f583a4a9
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers
On 2019-10-24 14:46, Sierra Guiza, Alejandro (Alex) wrote:
> The bitmap in cu_info structure is defined as a 4x4 size array. In
> Acturus, this matrix is initialized as a 4x2. Based on the 8 shaders.
> In the gpu cache filling initialization, the access to the bitmap matrix
> was done as an 8x1 ins
On 2019-10-22 14:28, Yang, Philip wrote:
> If device reset/suspend/resume failed for some reason, dqm lock is
> hold forever and this causes deadlock. Below is a kernel backtrace when
> application open kfd after suspend/resume failed.
>
> Instead of holding dqm lock in pre_reset and releasing dqm
suspended. But I'd
like to see some safeguards in place to make sure those assumptions are
never violated.
Regards,
Felix
>
> Regards,
> Oak
>
> -Original Message-
> From: amd-gfx On Behalf Of Kuehling,
> Felix
> Sent: Monday, October 21, 2019 9:04 PM
On 2019-10-21 5:04 p.m., Yang, Philip wrote:
> If device reset/suspend/resume failed for some reason, dqm lock is
> hold forever and this causes deadlock. Below is a kernel backtrace when
> application open kfd after suspend/resume failed.
>
> Instead of holding dqm lock in pre_reset and releasing
ters or send an
updated runlist to the HWS.
When the process is resumed at the end of the reset/suspend/eviction,
that's when any newly created queues would get mapped to the hardware.
Regards,
Felix
>
> Regards,
> Oak
>
> -Original Message-
> From: amd-gfx On
k on this myself. I'll create a ticket and see
if I can find someone to investigate.
Thanks,
Felix
>
> Andrey
>
> On 10/17/19 5:29 PM, Kuehling, Felix wrote:
>> I don't see why this problem would be specific to Arcturus. I don't see
>> any excessive
On 2019-10-18 4:29 p.m., Kim, Jonathan wrote:
> reverting the following changes:
> commit 7dd2eb31fcd5 ("drm/amdgpu: fix compiler warnings for df perfmons")
> commit 54275cd1649f ("drm/amdgpu: disable c-states on xgmi perfmons")
>
> perf events use spin-locks. embedded smu messages have potential
You can squash the two reverts into a single commit so you avoid
reintroducing a broken intermediate state. Mention both reverted commits
in the squashed commit description. Checkpatch.pl prefers a different
format for quoting reverted commits. Run checkpatch.pl on your commit to
see a proper e
On 2019-10-18 1:36 p.m., Yang, Philip wrote:
> If device is locked for suspend and resume, kfd open should return
> failed -EAGAIN without creating process, otherwise the application exit
> to release the process will hang to wait for resume is done if the suspend
> and resume is stuck somewhere. T
On 2019-10-18 10:27 a.m., Yang, Philip wrote:
> If device is locked for suspend and resume, kfd open should return
> failed -EAGAIN without creating process, otherwise the application exit
> to release the process will hang to wait for resume is done if the suspend
> and resume is stuck somewhere.
I don't see why this problem would be specific to Arcturus. I don't see
any excessive allocations on the stack either. Also the code involved
here hasn't changed recently.
Are you using some weird kernel config with a smaller stack? Is it
specific to a compiler version or some optimization flag
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
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-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-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-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-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-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
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-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
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-
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-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
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
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
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
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 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-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 +++
>
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-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
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 vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/am
On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
> Because we record the mapping under non HWS mode in the software,
> we can query pasid through vmid using the stored mapping instead of
> reading from ATC registers.
>
> This also prepares for the defeatured ATC block in future ASICs.
>
> Change-Id: I781
d . If that's the case , please
> specify this is for none hardware scheduler case in the header .
>
> Regards
>
> shaoyun.liu
>
> On 2019-09-26 4:07 p.m., Kuehling, Felix wrote:
>> On 2019-09-26 3:46 p.m., Zhao, Yong wrote:
>>> Because we record the mappin
On 2019-09-26 3:46 p.m., Zhao, Yong wrote:
> Because we record the mapping in the software, we can query pasid
> through vmid using the stored mapping instead of reading from ATC
> registers.
>
> This also prepares for the defeatured ATC block in future ASICs.
>
> Change-Id: I781cb9d30dc0cc93379908
On 2019-09-26 3:46 p.m., Zhao, Yong wrote:
> This makes possible the vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/amdkfd/kfd_device_queue_manager.c | 33 ---
> .../drm/amd/amdkf
Patches 1-3 and patch 5 are
Reviewed-by: Felix Kuehling
See separate emails for patches 4 and 6.
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> The GFX10 does not require the control stack to be right after mqd
> buffer any more, so move it back to usersapce allocated CSWR buffer.
>
> Change-Id:
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> get_atc_vmid_pasid_mapping_valid() is very similar to
> get_atc_vmid_pasid_mapping_pasid(), so they can be merged into a new
> function get_atc_vmid_pasid_mapping_info() to reduce register access
> times.
Hmm, the most important part may actually not be
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> This makes possible the vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/amdkfd/kfd_device_queue_manager.c | 34 +--
> .../drm/amd/amdkf
I sent out another change that set the asic_family as CHIP_NAVI10 since
>> from KFD side there is no difference for navi10 and navi12.
>>
>> Regards
>> Shaoyun.liu
>>
>> -Original Message-
>> From: Kuehling, Felix
>> Sent: Wednesday, Septembe
On 2019-09-25 2:15 p.m., Zhao, Yong wrote:
> The GFX10 does not have this hardware bug any more, so remove it.
I wouldn't call this a bug and a workaround. More like a change in the
HW or FW behaviour and a corresponding driver change. I.e. in GFXv8 the
control stack was in the user mode CWSR al
You'll also need to add "case CHIP_NAVI12:" in a bunch of places. Grep
for "CHIP_NAVI10" and you'll find them all pretty quickly.
Regards,
Felix
On 2019-09-24 6:13 p.m., Liu, Shaoyun wrote:
> Add device info for both navi12 PF and VF
>
> Change-Id: Ifb4035e65c12d153fc30e593fe109f9c7e0541f4
>
On 2019-09-18 12:30 p.m., Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/dri
I'm not disagreeing with the change. Just trying to understand how this
could have caused a VM fault. If the page tables are reserved or fenced
while you allocate a new one, they would not be evicted. If they are not
reserved or fenced, there should be no expectation that they stay resident.
Is
On 2019-09-16 12:33 p.m., Zhao, Yong wrote:
> These were deleted before, but somehow showed up again. Delete them again.
>
> Change-Id: I19b3063932380cb74a01d505e8e92f897a2c2cb7
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 4
>
On 2019-09-16 12:26 p.m., wrote:
> This was deleted before, but somehow showed up again. Delete it again.
>
> Change-Id: I19b3063932380cb74a01d505e8e92f897a2c2cb7
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/
On 2019-09-12 2:44 a.m., S, Shirish wrote:
> define sched_policy in case CONFIG_HSA_AMD is not
> enabled, with this there is no need to check for CONFIG_HSA_AMD
> else where in driver code.
>
> Suggested-by: Felix Kuehling
> Signed-off-by: Shirish S
Reviewed-by: Felix Kuehling
> ---
> drive
On 2019-09-12 2:58 a.m., S, Shirish wrote:
> On 9/12/2019 3:29 AM, Kuehling, Felix wrote:
>> On 2019-09-11 2:52 a.m., S, Shirish wrote:
>>> If CONFIG_HSA_AMD is not set, build fails:
>>>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
>>> `
On 2019-09-10 3:59 p.m., Russell, Kent wrote:
> This reverts commit e01f2d41895102d824c6b8f5e011dd5e286d5e8b.
>
> VG20 did not require this workaround, as the fix is in the VBIOS.
> Leave VG10/12 workaround as some older shipped cards do not have the
> VBIOS fix in place, and the kernel workaround
On 2019-09-11 2:52 a.m., S, Shirish wrote:
> If CONFIG_HSA_AMD is not set, build fails:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
> `amdgpu_device_ip_early_init':
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1626: undefined reference to
> `sched_policy'
>
> Use CONFIG_HSA_AMD to
This is pretty ugly. See a suggestion inline.
On 2019-09-10 4:12 a.m., Huang, Ray wrote:
>> -Original Message-
>> From: S, Shirish
>> Sent: Tuesday, September 10, 2019 3:54 PM
>> To: Deucher, Alexander ; Koenig, Christian
>> ; Huang, Ray
>> Cc: amd-gfx@lists.freedesktop.org; S, Shirish
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 ++-
1 file changed, 2 i
On 2019-09-05 3:22 p.m., Zhao, Yong wrote:
> Change-Id: Ie2c6226022ff4d389eaa05b1c84afa7ae4cea0aa
> Signed-off-by: Yong Zhao
Please add a change description. With that fixed, this patch is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 1 +
> drivers/g
On 2019-09-05 2:36 p.m., Huang, Ray wrote:
> This patch inits renoir kfd device info, so we treat renoir as "dgpu"
> (bypass iommu v2). Will enable needs_iommu_device till renoir iommu is ready.
>
> v2: rebase and align the drm-next
>
> Signed-off-by: Huang Rui
The series is
Reviewed-by: Felix K
On 2019-09-05 11:01, Zhao, Yong wrote:
> The issue was accidentally introduced recently.
>
> Change-Id: I3b21caa1596d4f7de1866bed1cb5d8fe1b51504c
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 --
> 1 file changed, 4 insertions
There is no point retrying page faults in VMID0. Those faults are
always fatal.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/mmhub_v2
On 2019-09-04 7:03 p.m., Huang, Ray wrote:
> On Wed, Sep 04, 2019 at 05:02:21PM +0200, Christian König wrote:
>> Hi everyone,
>>
>> this series is the next puzzle piece for recoverable page fault handling on
>> Vega and Navi.
>>
>> It adds a new direct scheduler entity for VM updates which is then
On 2019-09-04 11:02 a.m., Christian König wrote:
> Hi everyone,
>
> this series is the next puzzle piece for recoverable page fault handling on
> Vega and Navi.
>
> It adds a new direct scheduler entity for VM updates which is then used to
> update page tables during a fault.
>
> In other words
On 2019-09-04 11:02 a.m., Christian König wrote:
> For handling PDE updates directly in the fault handler.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> drivers/gpu/drm/amd/amdgpu
On 2019-09-04 11:02 a.m., Christian König wrote:
> Next step towards HMM support. For now just silence the retry fault and
> optionally redirect the request to the dummy page.
>
> v2: make sure the VM is not destroyed while we handle the fault.
>
> Signed-off-by: Christian König
> ---
> drivers/
On 2019-09-04 8:17 a.m., Christian König wrote:
> Move the ASIC specific code into a new callback function.
>
> v2: mask the flags for SI and CIK instead of a BUG_ON().
>
> Signed-off-by: Christian König
Nit-pick inline. Otherwise the series is
Reviewed-by: Felix Kuehling
> ---
> drivers/gp
Patches 2-10 are
Reviewed-by: Felix Kuehling
See my comments on patches 1 and 2 in separate emails. In patch 1 it
looks like you're based on an outdated version of the branch or a
different branch altogether. Please check that your series is based on
the latest amd-staging-drm-next.
Regards,
On 2019-09-04 11:48 a.m., Huang, Ray wrote:
> This patch inits renoir kfd device info, so we treat renoir as "dgpu"
> (bypass iommu v2). Will enable needs_iommu_device till renoir iommu is ready.
>
> Signed-off-by: Huang Rui
Looks good, but please coordinate with Yong who is changing the
structu
On 2019-09-04 11:48 a.m., Huang, Ray wrote:
> Renoir's cache info should be the same with raven and carrizo's.
>
> Signed-off-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> b/drive
On 2019-09-03 5:09 a.m., Christian König wrote:
> This hopefully helps reduce the contention for page tables.
>
> v2: adjust maximum reported VRAM size as well
>
> Signed-off-by: Christian König
I'll need to do something similar (and also take the vram_pin_size into
account) in amdgpu_amdkfd_res
On 2019-09-02 6:52 a.m., Christian König wrote:
> Make VM updates depend on the moving fence instead of the exclusive one.
In effect, this makes the page table update depend on the last move of
the BO, rather than the last change of the buffer contents. Makes sense.
Reviewed-by: Felix Kuehling
On 2019-09-02 10:57 a.m., Christian König wrote:
> Move the ASIC specific code into a new callback function.
NAK. I believe the BUG_ONs you're adding will trigger with ROCm on
Hawaii and Kaveri. See inline ...
ROCm user mode doesn't care that the page table doesn't have an
executable bit on tho
On 2019-08-30 12:39 p.m., Andrey Grodzovsky wrote:
> Problem:
> Under certain conditions, when some IP bocks take a RAS error,
> we can get into a situation where a GPU reset is not possible
> due to issues in RAS in SMU/PSP.
>
> Temporary fix until proper solution in PSP/SMU is ready:
> When uncor
On 2019-08-30 12:39 p.m., Andrey Grodzovsky wrote:
> Issue 1:
> In XGMI case amdgpu_device_lock_adev for other devices in hive
> was called to late, after access to their repsective schedulers.
> So relocate the lock to the begining of accessing the other devs.
>
> Issue 2:
> Using amdgpu_device_i
These wptrs must be pinned and GPU accessible when this is called
from hqd_load functions. So they should never fault. This resolves
a circular lock dependency issue involving four locks including the
DQM lock and mmap_sem.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdk
This workaround is better handled in user mode in a way that doesn't
require allocating extra memory and breaking userptr BOs.
The TLB bug is a performance bug, not a functional or security bug.
Hence it is safe to remove this kernel part of the workaround to
allow a better workaround using only v
On 2019-08-29 8:53 p.m., Andrey Grodzovsky wrote:
> Problem:
> Under certain conditions, when some IP bocks take a RAS error,
> we can get into a situation where a GPU reset is not possible
> due to issues in RAS in SMU/PSP.
>
> Temporary fix until proper solution in PSP/SMU is ready:
> When uncor
The same BO can be mapped with different PTE flags by different GPUs.
Therefore determine the PTE flags separately for each mapping instead
of storing them in the KFD buffer object.
Add a helper function to determine the PTE flags to be extended with
ASIC and memory-type-specific logic in subseque
On 2019-08-29 1:21 p.m., Grodzovsky, Andrey wrote:
> On 8/29/19 12:18 PM, Kuehling, Felix wrote:
>> On 2019-08-29 10:08 a.m., Grodzovsky, Andrey wrote:
>>> Agree, the placement of amdgpu_amdkfd_pre/post _reset in
>>> amdgpu_device_lock/unlock_adev is a bit wierd.
>&
1 - 100 of 558 matches
Mail list logo
