drm/amdgpu: give more chance for tlb flush if failed
Subsystems (2)
PATCH 1/1 drm/amdgpu: give more chance for tlb flush if failed
under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB
this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.
--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +19 -5
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev, {/* Use register 17 for GART */ const unsigned eng =17 ; -unsigned i, j; +unsigned i, j, loop =0 ; +unsigned flush_done =0 ; + +retry:spin_lock (&adev->gmc.invalidate_lock);for (i =0 ; i <AMDGPU_MAX_VMHUBS ; ++i) {struct amdgpu_vmhub *hub = &adev->vmhub[i];u32 tmp =gmc_v9_0_get_invalidate_req (vmid); +if (flush_done & (1 << i))/* this vmhub flushed */ +continue ;WREG32_NO_KIQ (hub->vm_inv_eng0_req + eng, tmp);
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,break ;cpu_relax (); } -if (j <100 ) +if (j <100 ) { + flush_done |= (1 << i);continue ; + }/* Wait for ACK with a delay.*/ for (j =0 ; j < adev->usec_timeout; j++) {
@@ -358,15 +365,22 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,break ;udelay (1 ); } -if (j < adev->usec_timeout) +if (j < adev->usec_timeout) { + flush_done |= (1 << i);continue ; - -DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }spin_unlock (&adev->gmc.invalidate_lock); +if (flush_done !=3 ) { +if (loop++ <3 ) + goto retry; +else +DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } } +static uint64_t gmc_v9_0_emit_flush_gpu_tlb (struct amdgpu_ring *ring,unsigned vmid,uint64_t pd_addr) {
Signature · 6 lines
2.7.4 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 1521527344-25641-1-git-send-email-Emily.Deng-5C7GfCeVMHo@public.gmane.org
Am 20.03.2018 um 07:29 schrieb Emily Deng:
Quoted 7 lines
under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB
this could fix the massive "Timeout waiting for VM flush ACK" error during
vk_encodertest.
Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.
What we did during debugging to avoid the problem is the following:
Quoted 15 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +4
-0@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(structamdgpu_device *adev, u32 tmp = gmc_v9_0_get_invalidate_req(vmid); WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp); + while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) != tmp) { + DRM_ERROR("Need one more try to write the VMHUB flush request!"); + WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp); + }
Quoted 2 lines
/* Busy wait for ACK.*/
for (j = 0; j < 100; j++) {
But that can only be a temporary workaround as well.
The question is rather can you reliable reproduce this issue with the vk_encoder test?
Thanks,
Christian.
Quoted 58 lines
Signed-off-by Monk Liu <[email protected]>--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-)drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +14
-5@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev, {/* Use register 17 for GART */ const unsigned eng =17 ; -unsigned i, j; +unsigned i, j, loop =0 ; +unsigned flush_done =0 ; + +retry:spin_lock (&adev->gmc.invalidate_lock);for (i =0 ; i <AMDGPU_MAX_VMHUBS ; ++i) {struct amdgpu_vmhub *hub = &adev->vmhub[i];u32 tmp =gmc_v9_0_get_invalidate_req (vmid); +if (flush_done & (1 << i))/* this vmhub flushed */ +continue ;WREG32_NO_KIQ (hub->vm_inv_eng0_req + eng, tmp);@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,break ;cpu_relax (); } -if (j <100 ) +if (j <100 ) { + flush_done |= (1 << i);continue ; + }/* Wait for ACK with a delay.*/ for (j =0 ; j < adev->usec_timeout; j++) {@@ -358,15 +365,22 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,break ;udelay (1 ); } -if (j < adev->usec_timeout) +if (j < adev->usec_timeout) { + flush_done |= (1 << i);continue ; - -DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }spin_unlock (&adev->gmc.invalidate_lock); +if (flush_done !=3 ) { +if (loop++ <3 )
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev, · line 386
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +5
-0+ goto retry; + else + DRM_ERROR("Timeout waiting for VM flush ACK!\n"); + } } +static uint64_t gmc_v9_0_emit_flush_gpu_tlb (struct amdgpu_ring *ring,unsigned vmid,uint64_t pd_addr) {
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 1a54a624-2816-c03f-bc75-da30be2ae48e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Hi Christian,
I agree with that the patch will hide the real problem, it is just a workaround, I will change the patch as you suggest.
as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the root cause.
I think the issue reproduce is reliable.
Best Wishes,
Emily Deng
Quoted 117 lines
-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failedAm 20.03.2018 um 07:29 schrieb Emily Deng:
Quoted 6 lines
under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB
this could fix the massive "Timeout waiting for VM flush ACK" error during
vk_encodertest.Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.
What we did during debugging to avoid the problem is the following:
Quoted 18 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-0@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(structamdgpu_device *adev, u32 tmp = gmc_v9_0_get_invalidate_req(vmid); WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp); + while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) != +tmp) { + DRM_ERROR("Need one more try to write the VMHUB flush request!"); + WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, +tmp); + }Quoted 2 lines
/* Busy wait for ACK.*/
for (j = 0; j < 100; j++) {But that can only be a temporary workaround as well.
The question is rather can you reliable reproduce this issue with the
vk_encodertest?Thanks,
Christian.Quoted 4 lines
Signed-off-by Monk Liu <[email protected]>--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++-----
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 8 lines
1 file changed, 19 insertions(+), 5 deletions(-)drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0
-0@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-1{/* Use register 17 for GART */ const unsigned eng =17 ; -unsigned i, j; +unsigned i, j, loop =0 ; +unsigned flush_done =0 ; + +retry:spin_lock (&adev->gmc.invalidate_lock);for (i =0 ; i <AMDGPU_MAX_VMHUBS ; ++i) {struct amdgpu_vmhub *hub = &adev->vmhub[i];u32 tmp =gmc_v9_0_get_invalidate_req (vmid); +if (flush_done & (1 << i))/* this vmhub flushed */ +continue ;WREG32_NO_KIQ (hub->vm_inv_eng0_req + eng, tmp);@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3
-1break ;cpu_relax (); } -if (j <100 ) +if (j <100 ) { + flush_done |= (1 << i);continue ; + }/* Wait for ACK with a delay.*/ for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22@@
Quoted 22 lines
static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,
break;
udelay(1);
}drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9
-3-if (j < adev->usec_timeout) +if (j < adev->usec_timeout) { + flush_done |= (1 << i);continue ; - -DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }spin_unlock (&adev->gmc.invalidate_lock); +if (flush_done !=3 ) { +if (loop++ <3 ) + goto retry; +else +DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }
Quoted 4 lines
Quoted 4 lines
+
staticuint64_tgmc_v9_0_emit_flush_gpu_tlb(structamdgpu_ring*ring,
unsigned vmid,uint64_tpd_addr)
{
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CY4PR12MB112582B8413D7323ADCDD97C8FA90-rpdhrqHFk07v2MZdTKcfDgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org
Quoted 1 line
I think the issue reproduce is reliable.
That is the really important thing.
We had the same issues with bare metal and working around them one by one didn't helped at all in the long run (e.g. Vega10 was still horrible unstable).
The only real solution was finding the root cause and eliminating it. For this issue as well as the one Monk investigated it turned out that reading some registers can cause problems when there are concurrent writes going on. E.g. the register read times out and leads to the write being dropped.
If those issues prevail even after eliminating all potential causes on your side we should probably setup a call with some hw people to discuss how to proceed further.
Regards,
Christian.
Am 22.03.2018 um 04:50 schrieb Deng, Emily:
Quoted 124 lines
Hi Christian,
I agree with that the patch will hide the real problem, it is just a workaround, I will change the patch as you suggest.
as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the root cause.
I think the issue reproduce is reliable.Best Wishes,
Emily DengQuoted 114 lines
-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failedAm 20.03.2018 um 07:29 schrieb Emily Deng:
Quoted 6 lines
under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB
this could fix the massive "Timeout waiting for VM flush ACK" error during
vk_encodertest.Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.
What we did during debugging to avoid the problem is the following:
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0
-0@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(structamdgpu_device *adev, u32 tmp = gmc_v9_0_get_invalidate_req(vmid); WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-0+ while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) != +tmp) { + DRM_ERROR("Need one more try to write the VMHUB flush request!"); + WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, +tmp); + } /* Busy wait for ACK.*/ for (j = 0; j < 100; j++) {But that can only be a temporary workaround as well.
The question is rather can you reliable reproduce this issue with the
vk_encodertest?Thanks,
Christian.Quoted 3 lines
Signed-off-by Monk Liu <[email protected]>--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++-----
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 8 lines
1 file changed, 19 insertions(+), 5 deletions(-)drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0
-0@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-1{/* Use register 17 for GART */ const unsigned eng =17 ; -unsigned i, j; +unsigned i, j, loop =0 ; +unsigned flush_done =0 ; + +retry:spin_lock (&adev->gmc.invalidate_lock);for (i =0 ; i <AMDGPU_MAX_VMHUBS ; ++i) {struct amdgpu_vmhub *hub = &adev->vmhub[i];u32 tmp =gmc_v9_0_get_invalidate_req (vmid); +if (flush_done & (1 << i))/* this vmhub flushed */ +continue ;WREG32_NO_KIQ (hub->vm_inv_eng0_req + eng, tmp);@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3
-1break ;cpu_relax (); } -if (j <100 ) +if (j <100 ) { + flush_done |= (1 << i);continue ; + }/* Wait for ACK with a delay.*/ for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22@@
Quoted 22 lines
static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,break; udelay(1); }drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9
-3-if (j < adev->usec_timeout) +if (j < adev->usec_timeout) { + flush_done |= (1 << i);continue ; - -DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }spin_unlock (&adev->gmc.invalidate_lock); +if (flush_done !=3 ) { +if (loop++ <3 ) + goto retry; +else +DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
+
staticuint64_tgmc_v9_0_emit_flush_gpu_tlb(structamdgpu_ring*ring,
unsigned vmid,uint64_tpd_addr)
{
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 50377594-10f9-8aec-1b2b-acd974527503-5C7GfCeVMHo@public.gmane.org
Hi Christian,
Right, maybe we could learn something from hardware, and find out the root cause.
Best Wishes,
Emily Deng
Quoted 155 lines
-----Original Message-----
From: Koenig, Christian
Sent: Thursday, March 22, 2018 4:54 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failedQuoted 1 line
I think the issue reproduce is reliable.
That is the really important thing.
We had the same issues with bare metal and working around them one by one didn't helped at all in the long run (e.g. Vega10 was still horrible unstable).
The only real solution was finding the root cause and eliminating it. For this issue as well as the one Monk investigated it turned out that reading some registers can cause problems when there are concurrent writes going on. E.g. the register read times out and leads to the write being dropped.
If those issues prevail even after eliminating all potential causes on your side we should probably setup a call with some hw people to discuss how to proceed further.
Regards,
Christian.Am 22.03.2018 um 04:50 schrieb Deng, Emily:
Quoted 2 lines
Hi Christian,
I agree with that the patch will hide the real problem, it is just aworkaround, I will change the patch as you suggest.
Quoted 2 lines
as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the
root cause.
Quoted 56 lines
I think the issue reproduce is reliable.
Best Wishes,
Emily DengQuoted 50 lines
-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failedAm 20.03.2018 um 07:29 schrieb Emily Deng:
Quoted 6 lines
under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB
this could fix the massive "Timeout waiting for VM flush ACK" error during
vk_encodertest.Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.
What we did during debugging to avoid the problem is the following:
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0
-0@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(structamdgpu_device *adev, u32 tmp = gmc_v9_0_get_invalidate_req(vmid); WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-0+ while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) != +tmp) { + DRM_ERROR("Need one more try to write the VMHUB flush request!"); + WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, +tmp); + } /* Busy wait for ACK.*/ for (j = 0; j < 100; j++) {But that can only be a temporary workaround as well.
The question is rather can you reliable reproduce this issue with the
vk_encodertest?Thanks,
Christian.Quoted 3 lines
Signed-off-by Monk Liu <[email protected]>--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24+++++++++++++++++++--
Quoted 65 lines
Quoted 65 lines
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 8 lines
1 file changed, 19 insertions(+), 5 deletions(-)drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0
-0@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct
Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6
-1{/* Use register 17 for GART */ const unsigned eng =17 ; -unsigned i, j; +unsigned i, j, loop =0 ; +unsigned flush_done =0 ; + +retry:spin_lock (&adev->gmc.invalidate_lock);for (i =0 ; i <AMDGPU_MAX_VMHUBS ; ++i) {struct amdgpu_vmhub *hub = &adev->vmhub[i];u32 tmp =gmc_v9_0_get_invalidate_req (vmid); +if (flush_done & (1 << i))/* this vmhub flushed */ +continue ;WREG32_NO_KIQ (hub->vm_inv_eng0_req + eng, tmp);@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct · line 361
Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3
-1break ;cpu_relax (); } -if (j <100 ) +if (j <100 ) { + flush_done |= (1 << i);continue ; + }/* Wait for ACK with a delay.*/ for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22@@
Quoted 22 lines
static void gmc_v9_0_flush_gpu_tlb(struct
amdgpu_device*adev,break; udelay(1); }drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9
-3-if (j < adev->usec_timeout) +if (j < adev->usec_timeout) { + flush_done |= (1 << i);continue ; - -DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }spin_unlock (&adev->gmc.invalidate_lock); +if (flush_done !=3 ) { +if (loop++ <3 ) + goto retry; +else +DRM_ERROR ("Timeout waiting for VM flush ACK!\n" ); + } }
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+
staticuint64_tgmc_v9_0_emit_flush_gpu_tlb(structamdgpu_ring*ring,
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
unsigned vmid, uint64_t pd_addr) {
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx