Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4d87f08e |
| 26-Mar-2024 |
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> |
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute qu
drm/amdkfd: Reset GPU on queue preemption failure
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
Currently, with F32 HWS GPU reset is only when unmap queue fails.
However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
45d72ead |
| 09-Oct-2023 |
Arvind Yadav <Arvind.Yadav@amd.com> |
drm/amdkfd: get doorbell's absolute offset based on the db_size
[ Upstream commit 367a0af43373d4f791cc8b466a659ecf5aa52377 ]
Here, Adding db_size in byte to find the doorbell's absolute offset for
drm/amdkfd: get doorbell's absolute offset based on the db_size
[ Upstream commit 367a0af43373d4f791cc8b466a659ecf5aa52377 ]
Here, Adding db_size in byte to find the doorbell's absolute offset for both 32-bit and 64-bit doorbell sizes. So that doorbell offset will be aligned based on the doorbell size.
v2: - Addressed the review comment from Felix. v3: - Adding doorbell_size as parameter to get db absolute offset. v4: Squash the two patches into one.
Cc: Christian Koenig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Arvind Yadav <Arvind.Yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.6, v6.5.5, v6.5.4 |
|
#
cc39f9cc |
| 14-Sep-2023 |
YuBiao Wang <YuBiao.Wang@amd.com> |
drm/amdkfd: Use gpu_offset for user queue's wptr
Directly use tbo's start address will miss the domain start offset. Need to use gpu_offset instead.
Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com>
drm/amdkfd: Use gpu_offset for user queue's wptr
Directly use tbo's start address will miss the domain start offset. Need to use gpu_offset instead.
Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
show more ...
|
Revision tags: v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50 |
|
#
81faf9e0 |
| 28-Aug-2023 |
Mukul Joshi <mukul.joshi@amd.com> |
drm/amdkfd: Fix reg offset for setting CWSR grace period
This patch fixes the case where the code currently passes absolute register address and not the reg offset, which HWS expects, when sending t
drm/amdkfd: Fix reg offset for setting CWSR grace period
This patch fixes the case where the code currently passes absolute register address and not the reg offset, which HWS expects, when sending the PM4 packet to set/update CWSR grace period. Additionally, cleanup the signature of build_grace_period_packet_info function as it no longer needs the inst parameter.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Jonathan Kim <jonathan.kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
Revision tags: v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45 |
|
#
8b4c350c |
| 10-Aug-2023 |
Jonathan Kim <jonathan.kim@amd.com> |
drm/amdkfd: fix double assign skip process context clear
Remove redundant assignment when skipping process ctx clear.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Felix Kuehling
drm/amdkfd: fix double assign skip process context clear
Remove redundant assignment when skipping process ctx clear.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
bd6040b0 |
| 09-Aug-2023 |
Atul Raut <rauji.raut@gmail.com> |
drm/amdkfd: Use memdup_user() rather than duplicating its implementation
To prevent its redundant implementation and streamline code, use memdup_user.
This fixes warnings reported by Coccinelle: ./
drm/amdkfd: Use memdup_user() rather than duplicating its implementation
To prevent its redundant implementation and streamline code, use memdup_user.
This fixes warnings reported by Coccinelle: ./drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:2811:13-20: WARNING opportunity for memdup_user
Signed-off-by: Atul Raut <rauji.raut@gmail.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
Revision tags: v6.1.44 |
|
#
80e28aaf |
| 07-Aug-2023 |
Alex Deucher <alexander.deucher@amd.com> |
drm/amdkfd: rename device_queue_manager_init_v10_navi10()
Drop the navi10 in the name for consistency with other families. All gfx10 parts use the same implementation.
Reviewed-by: Felix Kuehling
drm/amdkfd: rename device_queue_manager_init_v10_navi10()
Drop the navi10 in the name for consistency with other families. All gfx10 parts use the same implementation.
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
Revision tags: v6.1.43 |
|
#
c99a2e7a |
| 28-Jul-2023 |
Alex Deucher <alexander.deucher@amd.com> |
drm/amdkfd: drop IOMMUv2 support
Now that we use the dGPU path for all APUs, drop the IOMMUv2 support.
v2: drop the now unused queue manager functions for gfx7/8 APUs
Reviewed-by: Felix Kuehling <
drm/amdkfd: drop IOMMUv2 support
Now that we use the dGPU path for all APUs, drop the IOMMUv2 support.
v2: drop the now unused queue manager functions for gfx7/8 APUs
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
99c15019 |
| 28-Jul-2023 |
Alex Deucher <alexander.deucher@amd.com> |
drm/amdkfd: disable IOMMUv2 support for KV/CZ
Use the dGPU path instead. There were a lot of platform issues with IOMMU in general on these chips due to windows not enabling IOMMU at the time. The
drm/amdkfd: disable IOMMUv2 support for KV/CZ
Use the dGPU path instead. There were a lot of platform issues with IOMMU in general on these chips due to windows not enabling IOMMU at the time. The dGPU path has been used for a long time with newer APUs and works fine. This also paves the way to simplify the driver significantly.
v2: use the dGPU queue manager functions
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
616f92d1 |
| 28-Jul-2023 |
Alex Deucher <alexander.deucher@amd.com> |
drm/amdkfd: disable IOMMUv2 support for KV/CZ
Use the dGPU path instead. There were a lot of platform issues with IOMMU in general on these chips due to windows not enabling IOMMU at the time. The
drm/amdkfd: disable IOMMUv2 support for KV/CZ
Use the dGPU path instead. There were a lot of platform issues with IOMMU in general on these chips due to windows not enabling IOMMU at the time. The dGPU path has been used for a long time with newer APUs and works fine. This also paves the way to simplify the driver significantly.
v2: use the dGPU queue manager functions
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
2105a15a |
| 14-Jul-2023 |
Shashank Sharma <shashank.sharma@amd.com> |
drm/amdgpu: use doorbell mgr for kfd process doorbells
This patch: - adds a doorbell object in kfd pdd structure. - allocates doorbells for a process while creating its queue. - frees the doorbells
drm/amdgpu: use doorbell mgr for kfd process doorbells
This patch: - adds a doorbell object in kfd pdd structure. - allocates doorbells for a process while creating its queue. - frees the doorbells with pdd destroy. - moves doorbell bitmap init function to kfd_doorbell.c
PS: This patch ensures that we don't break the existing KFD functionality, but now KFD userspace library should also create doorbell pages as AMDGPU GEM objects using libdrm functions in userspace. The reference code for the same is available with AMDGPU Usermode queue libdrm MR. Once this is done, we will not need to create process doorbells in kernel.
V2: - Do not use doorbell wrapper API, use amdgpu_bo_create_kernel instead (Alex). - Do not use custom doorbell structure, instead use separate variables for bo and doorbell_bitmap (Alex) V3: - Do not allocate doorbell page with PDD, delay doorbell process page allocation until really needed (Felix)
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felilx.Kuehling@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
fc7f1d96 |
| 12-Jun-2023 |
Jonathan Kim <jonathan.kim@amd.com> |
drm/amdkfd: fix and enable ttmp setup for gfx11
The MES cached process context must be cleared on adding any queue for the first time.
For proper debug support, the MES will clear it's cached proce
drm/amdkfd: fix and enable ttmp setup for gfx11
The MES cached process context must be cleared on adding any queue for the first time.
For proper debug support, the MES will clear it's cached process context on the first call to SET_SHADER_DEBUGGER.
This allows TTMPs to be pesistently enabled in a safe manner.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Eric Huang <jinhuieric@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
602816c3 |
| 12-Jul-2023 |
Jonathan Kim <jonathan.kim@amd.com> |
drm/amdkfd: fix trap handling work around for debugging
Update the list of devices that require the cwsr trap handling workaround for debugging use cases.
Signed-off-by: Jonathan Kim <jonathan.kim@
drm/amdkfd: fix trap handling work around for debugging
Update the list of devices that require the cwsr trap handling workaround for debugging use cases.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Acked-by: Ruili Ji <ruili.ji@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
7a1c5c67 |
| 12-Jul-2023 |
Jonathan Kim <jonathan.kim@amd.com> |
drm/amdkfd: enable cooperative groups for gfx11
MES can concurrently schedule queues on the device that require exclusive device access if marked exclusively_scheduled without the requirement of GWS
drm/amdkfd: enable cooperative groups for gfx11
MES can concurrently schedule queues on the device that require exclusive device access if marked exclusively_scheduled without the requirement of GWS. Similar to the F32 HWS, MES will manage quality of service for these queues. Use this for cooperative groups since cooperative groups are device occupancy limited.
Since some GFX11 devices can only be debugged with partial CUs, do not allow the debugging of cooperative groups on these devices as the CU occupancy limit will change on attach.
In addition, zero initialize the MES add queue submission vector for MES initialization tests as we do not want these to be cooperative dispatches.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
cef600e1 |
| 12-Jul-2023 |
Jonathan Kim <jonathan.kim@amd.com> |
drm/amdkfd: fix trap handling work around for debugging
Update the list of devices that require the cwsr trap handling workaround for debugging use cases.
Signed-off-by: Jonathan Kim <jonathan.kim@
drm/amdkfd: fix trap handling work around for debugging
Update the list of devices that require the cwsr trap handling workaround for debugging use cases.
Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Acked-by: Ruili Ji <ruili.ji@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
1879e009 |
| 10-Jul-2023 |
Mukul Joshi <mukul.joshi@amd.com> |
drm/amdkfd: Update CWSR grace period for GFX9.4.3
For GFX9.4.3, setup a reduced default CWSR grace period equal to 1000 cycles instead of 64000 cycles.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.c
drm/amdkfd: Update CWSR grace period for GFX9.4.3
For GFX9.4.3, setup a reduced default CWSR grace period equal to 1000 cycles instead of 64000 cycles.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|