Re: [PATCH] drm/amdgpu: refine kiq read register
Am 2020-04-20 um 3:42 a.m. schrieb Tao, Yintian: > Hi Felix > > I have one question about function kgd_gfx_v9_hiq_mqd_load(). I see it > directly write contents into kiq ring and not wait for the fence. Do you know > how KFD know the hiq_mqd_load complete? Thanks in advance. That's probably a bug. I think we can get away with it, because the HIQ is only used once the first user mode KFD process is started. Worst case, KFD will submit something to the HIQ before it's mapped, and the doorbell update will be missed. So KFD will think the HIQ is hanging and trigger a GPU reset. Regards, Felix > > > > Best Regards > Yintian Tao ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: refine kiq read register
[AMD Official Use Only - Internal Distribution Only] I didn't calculate the exact required DW used for on e kiq read ( currently use 32 DW) , That's assume it's right , Can we just alloc 2 more here ? Since each kiq_read will do the allocation , it won't conflict with other read operation. Shaoyun.liu -Original Message- From: amd-gfx On Behalf Of Liu, Monk Sent: Monday, April 20, 2020 5:28 AM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register So why don't we let gpu scheduler to manage KIQ, and all client of KIQ need to submit jobs within an IB ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:48 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, yeah, that is certainly problematic. But we have some maximum size for the KIQ submission, don't we? The only alternative would be to double check the rptr before we allocate space on the ring buffer, but this means quite some additional overhead. Regards, Christian. Am 20.04.20 um 10:36 schrieb Liu, Monk: > No, that's not true > > The problem is not we submit commands on KIQ ring before the emiited > ones are signaled , instead it is because we don't have a unified > command submit size on KIQ > > e.g.: > > ---JOB1---JOB2---JOB3---JOB4--->> > If job1 signaled and job 2/3/4 are running, by (your) design driver is > allowed to put job5 on the position of job1. But there is chance that > job5 take 100DW while job1 only occupy 50dw, thus the job2 will be > overwritten by job5\ > > By gpu scheduler we always have fixed size of commands so jo5 will not > overwrite job 2. > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Koenig, Christian > Sent: Monday, April 20, 2020 4:26 PM > To: Liu, Monk ; Kuehling, Felix > ; Tao, Yintian > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > That is actually only a problem because the KIQ uses polling waits. > > See amdgpu_fence_emit() waits for the oldest possible fence to be signaled > before emitting a new one. > > I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner > like the following should be enough: > > amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, > timeout); > > Regards, > Christian. > > Am 20.04.20 um 10:20 schrieb Liu, Monk: >> Sure, that's fine >> >> Do you have particular suggestion for problem 2 ? how we avoid >> commands being overwritten before it's finished >> >> _ >> Monk Liu|GPU Virtualization Team |AMD >> >> >> -Original Message- >> From: Christian König >> Sent: Monday, April 20, 2020 4:17 PM >> To: Liu, Monk ; Koenig, Christian >> ; Kuehling, Felix ; >> Tao, Yintian >> Cc: amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: refine kiq read register >> >>> Yintian's patch has nothing to do with the result you mentioned the >>> command being overwritten by new initiated commands is a inherent bug, why >>> you put those two stuff together ? >> Yintian patch made the situation absolutely worse. Instead of a whole ring >> buffer wrap around to overwrite things (1024 dw at least) you now just need >> to use up 30 dw to trigger undefined behavior and most likely a lockup. >> >> And as Felix pointed out the patch even writes over the end of the ring >> buffer and can cause random corruption to whatever there is. >> >>> What about let Yintian to provide one patch to address all those two >>> problem ? so way what you worried about won't happen ? >> Yes, please do so. But please make also sure that the original patch is >> reverted before this starts to cause fallout from testers. >> >> Regards, >> Christian. >> >> Am 20.04.20 um 09:39 schrieb Liu, Monk: >>>>>> Instead of this crude hack please let us just allocate a fixed >>>>>> number of write back slots and use them round robin >>> It looks doable but really ugly compared with current patch ... and >>> more over there we are going to fix the second problem eventually >>> >>> What about let Yintian to provide one patch to address all those two >>> problem ? so way what you worried about won't happen
Re: [PATCH] drm/amdgpu: refine kiq read register
That's what we did initially, but we need to use the KIQ in atomic context and that doesn't work with the scheduler. Additional to that the scheduler has the same problem as the direct submit, you need to know how what the maximum dw is a job could take. Christian. Am 20.04.20 um 11:28 schrieb Liu, Monk: So why don't we let gpu scheduler to manage KIQ, and all client of KIQ need to submit jobs within an IB ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:48 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, yeah, that is certainly problematic. But we have some maximum size for the KIQ submission, don't we? The only alternative would be to double check the rptr before we allocate space on the ring buffer, but this means quite some additional overhead. Regards, Christian. Am 20.04.20 um 10:36 schrieb Liu, Monk: No, that's not true The problem is not we submit commands on KIQ ring before the emiited ones are signaled , instead it is because we don't have a unified command submit size on KIQ e.g.: ---JOB1---JOB2---JOB3---JOB4--->> If job1 signaled and job 2/3/4 are running, by (your) design driver is allowed to put job5 on the position of job1. But there is chance that job5 take 100DW while job1 only occupy 50dw, thus the job2 will be overwritten by job5\ By gpu scheduler we always have fixed size of commands so jo5 will not overwrite job 2. _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 4:26 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register That is actually only a problem because the KIQ uses polling waits. See amdgpu_fence_emit() waits for the oldest possible fence to be signaled before emitting a new one. I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like the following should be enough: amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, timeout); Regards, Christian. Am 20.04.20 um 10:20 schrieb Liu, Monk: Sure, that's fine Do you have particular suggestion for problem 2 ? how we avoid commands being overwritten before it's finished _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:17 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? Yintian patch made the situation absolutely worse. Instead of a whole ring buffer wrap around to overwrite things (1024 dw at least) you now just need to use up 30 dw to trigger undefined behavior and most likely a lockup. And as Felix pointed out the patch even writes over the end of the ring buffer and can cause random corruption to whatever there is. What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? Yes, please do so. But please make also sure that the original patch is reverted before this starts to cause fallout from testers. Regards, Christian. Am 20.04.20 um 09:39 schrieb Liu, Monk: Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin It looks doable but really ugly compared with current patch ... and more over there we are going to fix the second problem eventually What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Liu, Monk Sent: Monday, April 20, 2020 3:37 PM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc
RE: [PATCH] drm/amdgpu: refine kiq read register
So why don't we let gpu scheduler to manage KIQ, and all client of KIQ need to submit jobs within an IB ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:48 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, yeah, that is certainly problematic. But we have some maximum size for the KIQ submission, don't we? The only alternative would be to double check the rptr before we allocate space on the ring buffer, but this means quite some additional overhead. Regards, Christian. Am 20.04.20 um 10:36 schrieb Liu, Monk: > No, that's not true > > The problem is not we submit commands on KIQ ring before the emiited > ones are signaled , instead it is because we don't have a unified > command submit size on KIQ > > e.g.: > > ---JOB1---JOB2---JOB3---JOB4--->> > If job1 signaled and job 2/3/4 are running, by (your) design driver is > allowed to put job5 on the position of job1. But there is chance that > job5 take 100DW while job1 only occupy 50dw, thus the job2 will be > overwritten by job5\ > > By gpu scheduler we always have fixed size of commands so jo5 will not > overwrite job 2. > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Koenig, Christian > Sent: Monday, April 20, 2020 4:26 PM > To: Liu, Monk ; Kuehling, Felix > ; Tao, Yintian > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > That is actually only a problem because the KIQ uses polling waits. > > See amdgpu_fence_emit() waits for the oldest possible fence to be signaled > before emitting a new one. > > I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner > like the following should be enough: > > amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, > timeout); > > Regards, > Christian. > > Am 20.04.20 um 10:20 schrieb Liu, Monk: >> Sure, that's fine >> >> Do you have particular suggestion for problem 2 ? how we avoid >> commands being overwritten before it's finished >> >> _ >> Monk Liu|GPU Virtualization Team |AMD >> >> >> -Original Message- >> From: Christian König >> Sent: Monday, April 20, 2020 4:17 PM >> To: Liu, Monk ; Koenig, Christian >> ; Kuehling, Felix ; >> Tao, Yintian >> Cc: amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: refine kiq read register >> >>> Yintian's patch has nothing to do with the result you mentioned the >>> command being overwritten by new initiated commands is a inherent bug, why >>> you put those two stuff together ? >> Yintian patch made the situation absolutely worse. Instead of a whole ring >> buffer wrap around to overwrite things (1024 dw at least) you now just need >> to use up 30 dw to trigger undefined behavior and most likely a lockup. >> >> And as Felix pointed out the patch even writes over the end of the ring >> buffer and can cause random corruption to whatever there is. >> >>> What about let Yintian to provide one patch to address all those two >>> problem ? so way what you worried about won't happen ? >> Yes, please do so. But please make also sure that the original patch is >> reverted before this starts to cause fallout from testers. >> >> Regards, >> Christian. >> >> Am 20.04.20 um 09:39 schrieb Liu, Monk: >>>>>> Instead of this crude hack please let us just allocate a fixed >>>>>> number of write back slots and use them round robin >>> It looks doable but really ugly compared with current patch ... and >>> more over there we are going to fix the second problem eventually >>> >>> What about let Yintian to provide one patch to address all those two >>> problem ? so way what you worried about won't happen ? >>> _ >>> Monk Liu|GPU Virtualization Team |AMD >>> >>> >>> -Original Message- >>> From: Liu, Monk >>> Sent: Monday, April 20, 2020 3:37 PM >>> To: Koenig, Christian ; Kuehling, Felix >>> ; Tao, Yintian >>> Cc: amd-gfx@lists.freedesktop.org >>> Subject: RE: [PATCH] drm/amdgpu: refine kiq read register >>> >>>>>> Previously we ended up with an invalid value in a concurrent register >>&
Re: [PATCH] drm/amdgpu: refine kiq read register
Hi Monk, yeah, that is certainly problematic. But we have some maximum size for the KIQ submission, don't we? The only alternative would be to double check the rptr before we allocate space on the ring buffer, but this means quite some additional overhead. Regards, Christian. Am 20.04.20 um 10:36 schrieb Liu, Monk: No, that's not true The problem is not we submit commands on KIQ ring before the emiited ones are signaled , instead it is because we don't have a unified command submit size on KIQ e.g.: ---JOB1---JOB2---JOB3---JOB4--->> If job1 signaled and job 2/3/4 are running, by (your) design driver is allowed to put job5 on the position of job1. But there is chance that job5 take 100DW while job1 only occupy 50dw, thus the job2 will be overwritten by job5\ By gpu scheduler we always have fixed size of commands so jo5 will not overwrite job 2. _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 4:26 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register That is actually only a problem because the KIQ uses polling waits. See amdgpu_fence_emit() waits for the oldest possible fence to be signaled before emitting a new one. I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like the following should be enough: amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, timeout); Regards, Christian. Am 20.04.20 um 10:20 schrieb Liu, Monk: Sure, that's fine Do you have particular suggestion for problem 2 ? how we avoid commands being overwritten before it's finished _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:17 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? Yintian patch made the situation absolutely worse. Instead of a whole ring buffer wrap around to overwrite things (1024 dw at least) you now just need to use up 30 dw to trigger undefined behavior and most likely a lockup. And as Felix pointed out the patch even writes over the end of the ring buffer and can cause random corruption to whatever there is. What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? Yes, please do so. But please make also sure that the original patch is reverted before this starts to cause fallout from testers. Regards, Christian. Am 20.04.20 um 09:39 schrieb Liu, Monk: Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin It looks doable but really ugly compared with current patch ... and more over there we are going to fix the second problem eventually What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Liu, Monk Sent: Monday, April 20, 2020 3:37 PM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduc
RE: [PATCH] drm/amdgpu: refine kiq read register
No, that's not true The problem is not we submit commands on KIQ ring before the emiited ones are signaled , instead it is because we don't have a unified command submit size on KIQ e.g.: ---JOB1---JOB2---JOB3---JOB4--->> If job1 signaled and job 2/3/4 are running, by (your) design driver is allowed to put job5 on the position of job1. But there is chance that job5 take 100DW while job1 only occupy 50dw, thus the job2 will be overwritten by job5\ By gpu scheduler we always have fixed size of commands so jo5 will not overwrite job 2. _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 4:26 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register That is actually only a problem because the KIQ uses polling waits. See amdgpu_fence_emit() waits for the oldest possible fence to be signaled before emitting a new one. I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like the following should be enough: amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, timeout); Regards, Christian. Am 20.04.20 um 10:20 schrieb Liu, Monk: > Sure, that's fine > > Do you have particular suggestion for problem 2 ? how we avoid > commands being overwritten before it's finished > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Christian König > Sent: Monday, April 20, 2020 4:17 PM > To: Liu, Monk ; Koenig, Christian > ; Kuehling, Felix ; > Tao, Yintian > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > >> Yintian's patch has nothing to do with the result you mentioned the >> command being overwritten by new initiated commands is a inherent bug, why >> you put those two stuff together ? > Yintian patch made the situation absolutely worse. Instead of a whole ring > buffer wrap around to overwrite things (1024 dw at least) you now just need > to use up 30 dw to trigger undefined behavior and most likely a lockup. > > And as Felix pointed out the patch even writes over the end of the ring > buffer and can cause random corruption to whatever there is. > >> What about let Yintian to provide one patch to address all those two >> problem ? so way what you worried about won't happen ? > Yes, please do so. But please make also sure that the original patch is > reverted before this starts to cause fallout from testers. > > Regards, > Christian. > > Am 20.04.20 um 09:39 schrieb Liu, Monk: >>>>> Instead of this crude hack please let us just allocate a fixed >>>>> number of write back slots and use them round robin >> It looks doable but really ugly compared with current patch ... and >> more over there we are going to fix the second problem eventually >> >> What about let Yintian to provide one patch to address all those two >> problem ? so way what you worried about won't happen ? >> _ >> Monk Liu|GPU Virtualization Team |AMD >> >> >> -----Original Message- >> From: Liu, Monk >> Sent: Monday, April 20, 2020 3:37 PM >> To: Koenig, Christian ; Kuehling, Felix >> ; Tao, Yintian >> Cc: amd-gfx@lists.freedesktop.org >> Subject: RE: [PATCH] drm/amdgpu: refine kiq read register >> >>>>> Previously we ended up with an invalid value in a concurrent register >>>>> read, now the KIQs overwrites its own commands and most likely causes a >>>>> hang or the hardware to execute something random. >> Yintian's patch has nothing to do with the result you mentioned the >> command being overwritten by new initiated commands is a inherent bug, why >> you put those two stuff together ? >> >> >> >> _ >> Monk Liu|GPU Virtualization Team |AMD >> >> >> -Original Message- >> From: Koenig, Christian >> Sent: Monday, April 20, 2020 3:19 PM >> To: Liu, Monk ; Kuehling, Felix >> ; Tao, Yintian >> Cc: amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: refine kiq read register >> >> Hi Monk, >> >>> Can we first get the first problem done ? >> Please absolutely not! See the problem introduced here is quite worse than >> the actual fix. >> >> Previously we ended up with an invalid value in a concurrent register read, >> now the KIQs overwrites its own commands and most likely causes a hang or >>
Re: [PATCH] drm/amdgpu: refine kiq read register
That is actually only a problem because the KIQ uses polling waits. See amdgpu_fence_emit() waits for the oldest possible fence to be signaled before emitting a new one. I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like the following should be enough: amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask, timeout); Regards, Christian. Am 20.04.20 um 10:20 schrieb Liu, Monk: Sure, that's fine Do you have particular suggestion for problem 2 ? how we avoid commands being overwritten before it's finished _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:17 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? Yintian patch made the situation absolutely worse. Instead of a whole ring buffer wrap around to overwrite things (1024 dw at least) you now just need to use up 30 dw to trigger undefined behavior and most likely a lockup. And as Felix pointed out the patch even writes over the end of the ring buffer and can cause random corruption to whatever there is. What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? Yes, please do so. But please make also sure that the original patch is reverted before this starts to cause fallout from testers. Regards, Christian. Am 20.04.20 um 09:39 schrieb Liu, Monk: Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin It looks doable but really ugly compared with current patch ... and more over there we are going to fix the second problem eventually What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Liu, Monk Sent: Monday, April 20, 2020 3:37 PM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduce another potential problematic hack. If this patch is already committed please revert it immediately. Regards, Christian. Am 20.04.20 um 08:20 schrieb Liu, Monk: Christian Well I was under the assumption that this is actually what is done here. If that is not the case the patch is a rather clear NAK. <<< There are two kinds of problems in the current KIQ reading reg, Yintian tend to fix one of them but not all ... The first problem is : During the sleep of the first KIQ reading, another KIQ reading initiated an the read back register value flushed the first readback value, thus the first reading will get the wrong result. This is the issue yintian's patch to address, by put the readback value not in a shared WB but in a chunk DW of command submit The second problem is: Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is busy with some commands then those unfinished commands maybe overwritten by a new command submit, and that's not the Problem yintian's patch tend to address. Felex pointed it out which is fine and we can use another patch to address it, I'm also planning and scoping it. The optional way is: 1) We use GPU schedul
RE: [PATCH] drm/amdgpu: refine kiq read register
Sure, that's fine Do you have particular suggestion for problem 2 ? how we avoid commands being overwritten before it's finished _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 4:17 PM To: Liu, Monk ; Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > Yintian's patch has nothing to do with the result you mentioned the > command being overwritten by new initiated commands is a inherent bug, why > you put those two stuff together ? Yintian patch made the situation absolutely worse. Instead of a whole ring buffer wrap around to overwrite things (1024 dw at least) you now just need to use up 30 dw to trigger undefined behavior and most likely a lockup. And as Felix pointed out the patch even writes over the end of the ring buffer and can cause random corruption to whatever there is. > What about let Yintian to provide one patch to address all those two problem > ? so way what you worried about won't happen ? Yes, please do so. But please make also sure that the original patch is reverted before this starts to cause fallout from testers. Regards, Christian. Am 20.04.20 um 09:39 schrieb Liu, Monk: >>>> Instead of this crude hack please let us just allocate a fixed >>>> number of write back slots and use them round robin > It looks doable but really ugly compared with current patch ... and > more over there we are going to fix the second problem eventually > > What about let Yintian to provide one patch to address all those two problem > ? so way what you worried about won't happen ? > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Liu, Monk > Sent: Monday, April 20, 2020 3:37 PM > To: Koenig, Christian ; Kuehling, Felix > ; Tao, Yintian > Cc: amd-gfx@lists.freedesktop.org > Subject: RE: [PATCH] drm/amdgpu: refine kiq read register > >>>> Previously we ended up with an invalid value in a concurrent register >>>> read, now the KIQs overwrites its own commands and most likely causes a >>>> hang or the hardware to execute something random. > Yintian's patch has nothing to do with the result you mentioned the > command being overwritten by new initiated commands is a inherent bug, why > you put those two stuff together ? > > > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Koenig, Christian > Sent: Monday, April 20, 2020 3:19 PM > To: Liu, Monk ; Kuehling, Felix > ; Tao, Yintian > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > Hi Monk, > >> Can we first get the first problem done ? > Please absolutely not! See the problem introduced here is quite worse than > the actual fix. > > Previously we ended up with an invalid value in a concurrent register read, > now the KIQs overwrites its own commands and most likely causes a hang or the > hardware to execute something random. > > Instead of this crude hack please let us just allocate a fixed number of > write back slots and use them round robin. Then we can make sure that we > don't have more than a fixed number of reads in flight at the same time as > well using the fence values. > > This should fix both problems at the same time and not introduce another > potential problematic hack. > > If this patch is already committed please revert it immediately. > > Regards, > Christian. > > Am 20.04.20 um 08:20 schrieb Liu, Monk: >> Christian >> >>>>> Well I was under the assumption that this is actually what is done here. >> If that is not the case the patch is a rather clear NAK. >> <<< >> >> There are two kinds of problems in the current KIQ reading reg, Yintian tend >> to fix one of them but not all ... >> >> The first problem is : >> During the sleep of the first KIQ reading, another KIQ reading initiated an >> the read back register value flushed the first readback value, thus the >> first reading will get the wrong result. >> This is the issue yintian's patch to address, by put the readback >> value not in a shared WB but in a chunk DW of command submit >> >> The second problem is: >> Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ >> is busy with some commands then those unfinished commands maybe overwritten >> by a new command submit, and that's not the Problem yintian's patch tend to >> address. Felex p
Re: [PATCH] drm/amdgpu: refine kiq read register
Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? Yintian patch made the situation absolutely worse. Instead of a whole ring buffer wrap around to overwrite things (1024 dw at least) you now just need to use up 30 dw to trigger undefined behavior and most likely a lockup. And as Felix pointed out the patch even writes over the end of the ring buffer and can cause random corruption to whatever there is. What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? Yes, please do so. But please make also sure that the original patch is reverted before this starts to cause fallout from testers. Regards, Christian. Am 20.04.20 um 09:39 schrieb Liu, Monk: Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin It looks doable but really ugly compared with current patch ... and more over there we are going to fix the second problem eventually What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Liu, Monk Sent: Monday, April 20, 2020 3:37 PM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduce another potential problematic hack. If this patch is already committed please revert it immediately. Regards, Christian. Am 20.04.20 um 08:20 schrieb Liu, Monk: Christian Well I was under the assumption that this is actually what is done here. If that is not the case the patch is a rather clear NAK. <<< There are two kinds of problems in the current KIQ reading reg, Yintian tend to fix one of them but not all ... The first problem is : During the sleep of the first KIQ reading, another KIQ reading initiated an the read back register value flushed the first readback value, thus the first reading will get the wrong result. This is the issue yintian's patch to address, by put the readback value not in a shared WB but in a chunk DW of command submit The second problem is: Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is busy with some commands then those unfinished commands maybe overwritten by a new command submit, and that's not the Problem yintian's patch tend to address. Felex pointed it out which is fine and we can use another patch to address it, I'm also planning and scoping it. The optional way is: 1) We use GPU scheduler to manage KIQ activity, and all jobs are submitted to KIQ through a IB, thus no overwritten will happen 2) we still skip gpu scheduler but always use IB to put jobs on KIQ, thus each JOB will occupy the fixed space/DW of RB, so we can avoid overwrite unfinished command We can discuss the second problem later Can we first get the first problem done ? thanks _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Christian König Sent: Monday, April 20, 2020 1:03 AM To: Kuehling, Felix ; Tao, Yintian ; Liu, Monk Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Am 17.04.20 um 17:39 schrieb Felix Kuehling: Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao: According to the current kiq read register method, there will be race condition when using KIQ to read register if multipl
RE: [PATCH] drm/amdgpu: refine kiq read register
Hi Christian This patch has not been merged because it is still under discussion among you, Monk and Felix. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. [yttao]: Yes, the fixed number of write back slots can also fix the problem-1 which Monk described but it still can't fix the problem-2. But it seems the fixed number solution can fix one potential bug raised by msleep() when kiq read register. Because currently there is no protect mechanism for KIQ ring submission. Now, there are 5 submitter which can infinitely write kiq ring buffer without any limitation. 1. kiq read/write register 2. amdgpu_vm_flush 3. invalidate tlb 4. kfd hiq_mqd_load Hi Felix I have one question about function kgd_gfx_v9_hiq_mqd_load(). I see it directly write contents into kiq ring and not wait for the fence. Do you know how KFD know the hiq_mqd_load complete? Thanks in advance. Best Regards Yintian Tao -Original Message- From: Koenig, Christian Sent: 2020年4月20日 15:19 To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, > Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduce another potential problematic hack. If this patch is already committed please revert it immediately. Regards, Christian. Am 20.04.20 um 08:20 schrieb Liu, Monk: > Christian > >>>> Well I was under the assumption that this is actually what is done here. > If that is not the case the patch is a rather clear NAK. > <<< > > There are two kinds of problems in the current KIQ reading reg, Yintian tend > to fix one of them but not all ... > > The first problem is : > During the sleep of the first KIQ reading, another KIQ reading initiated an > the read back register value flushed the first readback value, thus the first > reading will get the wrong result. > This is the issue yintian's patch to address, by put the readback > value not in a shared WB but in a chunk DW of command submit > > The second problem is: > Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is > busy with some commands then those unfinished commands maybe overwritten by a > new command submit, and that's not the Problem yintian's patch tend to > address. Felex pointed it out which is fine and we can use another patch to > address it, I'm also planning and scoping it. > > The optional way is: > 1) We use GPU scheduler to manage KIQ activity, and all jobs are > submitted to KIQ through a IB, thus no overwritten will happen > 2) we still skip gpu scheduler but always use IB to put jobs on KIQ, > thus each JOB will occupy the fixed space/DW of RB, so we can avoid > overwrite unfinished command > > We can discuss the second problem later > > Can we first get the first problem done ? thanks > > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Christian König > Sent: Monday, April 20, 2020 1:03 AM > To: Kuehling, Felix ; Tao, Yintian > ; Liu, Monk > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > Am 17.04.20 um 17:39 schrieb Felix Kuehling: >> Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao: >>> According to the current kiq read register method, there will be >>> race condition when using KIQ to read register if multiple clients >>> want to read at same time just like the expample below: >>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the >>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll >>> the seqno-1 5. the kiq complete these two read operation 6. client-A >>> to read the register at the wb buffer and >>> get REG-1 value >>> >>> Therefore, directly make kiq write the register value at the ring >>> buffer then there will be no race condition for the wb buffer. >>> >>> v2: supply th
RE: [PATCH] drm/amdgpu: refine kiq read register
>>> Instead of this crude hack please let us just allocate a fixed number of >>> write back slots and use them round robin It looks doable but really ugly compared with current patch ... and more over there we are going to fix the second problem eventually What about let Yintian to provide one patch to address all those two problem ? so way what you worried about won't happen ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Liu, Monk Sent: Monday, April 20, 2020 3:37 PM To: Koenig, Christian ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu: refine kiq read register >>> Previously we ended up with an invalid value in a concurrent register read, >>> now the KIQs overwrites its own commands and most likely causes a hang or >>> the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, > Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduce another potential problematic hack. If this patch is already committed please revert it immediately. Regards, Christian. Am 20.04.20 um 08:20 schrieb Liu, Monk: > Christian > >>>> Well I was under the assumption that this is actually what is done here. > If that is not the case the patch is a rather clear NAK. > <<< > > There are two kinds of problems in the current KIQ reading reg, Yintian tend > to fix one of them but not all ... > > The first problem is : > During the sleep of the first KIQ reading, another KIQ reading initiated an > the read back register value flushed the first readback value, thus the first > reading will get the wrong result. > This is the issue yintian's patch to address, by put the readback > value not in a shared WB but in a chunk DW of command submit > > The second problem is: > Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is > busy with some commands then those unfinished commands maybe overwritten by a > new command submit, and that's not the Problem yintian's patch tend to > address. Felex pointed it out which is fine and we can use another patch to > address it, I'm also planning and scoping it. > > The optional way is: > 1) We use GPU scheduler to manage KIQ activity, and all jobs are > submitted to KIQ through a IB, thus no overwritten will happen > 2) we still skip gpu scheduler but always use IB to put jobs on KIQ, > thus each JOB will occupy the fixed space/DW of RB, so we can avoid > overwrite unfinished command > > We can discuss the second problem later > > Can we first get the first problem done ? thanks > > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Christian König > Sent: Monday, April 20, 2020 1:03 AM > To: Kuehling, Felix ; Tao, Yintian > ; Liu, Monk > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > Am 17.04.20 um 17:39 schrieb Felix Kuehling: >> Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao: >>> According to the current kiq read register method, there will be >>> race condition when using KIQ to read register if multiple clients >>> want to read at same time just like the expample below: >>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the >>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll >>> the seqno-1 5. the kiq complete these two read operation 6. client-A >>> to read the register at the wb buffer and >>> get REG-1 value >>> >>> Therefore, directly make kiq write the register value at the ring >>> buffer th
RE: [PATCH] drm/amdgpu: refine kiq read register
>>> Previously we ended up with an invalid value in a concurrent register read, >>> now the KIQs overwrites its own commands and most likely causes a hang or >>> the hardware to execute something random. Yintian's patch has nothing to do with the result you mentioned the command being overwritten by new initiated commands is a inherent bug, why you put those two stuff together ? _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Koenig, Christian Sent: Monday, April 20, 2020 3:19 PM To: Liu, Monk ; Kuehling, Felix ; Tao, Yintian Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq read register Hi Monk, > Can we first get the first problem done ? Please absolutely not! See the problem introduced here is quite worse than the actual fix. Previously we ended up with an invalid value in a concurrent register read, now the KIQs overwrites its own commands and most likely causes a hang or the hardware to execute something random. Instead of this crude hack please let us just allocate a fixed number of write back slots and use them round robin. Then we can make sure that we don't have more than a fixed number of reads in flight at the same time as well using the fence values. This should fix both problems at the same time and not introduce another potential problematic hack. If this patch is already committed please revert it immediately. Regards, Christian. Am 20.04.20 um 08:20 schrieb Liu, Monk: > Christian > >>>> Well I was under the assumption that this is actually what is done here. > If that is not the case the patch is a rather clear NAK. > <<< > > There are two kinds of problems in the current KIQ reading reg, Yintian tend > to fix one of them but not all ... > > The first problem is : > During the sleep of the first KIQ reading, another KIQ reading initiated an > the read back register value flushed the first readback value, thus the first > reading will get the wrong result. > This is the issue yintian's patch to address, by put the readback > value not in a shared WB but in a chunk DW of command submit > > The second problem is: > Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is > busy with some commands then those unfinished commands maybe overwritten by a > new command submit, and that's not the Problem yintian's patch tend to > address. Felex pointed it out which is fine and we can use another patch to > address it, I'm also planning and scoping it. > > The optional way is: > 1) We use GPU scheduler to manage KIQ activity, and all jobs are > submitted to KIQ through a IB, thus no overwritten will happen > 2) we still skip gpu scheduler but always use IB to put jobs on KIQ, > thus each JOB will occupy the fixed space/DW of RB, so we can avoid > overwrite unfinished command > > We can discuss the second problem later > > Can we first get the first problem done ? thanks > > > _ > Monk Liu|GPU Virtualization Team |AMD > > > -Original Message- > From: Christian König > Sent: Monday, April 20, 2020 1:03 AM > To: Kuehling, Felix ; Tao, Yintian > ; Liu, Monk > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq read register > > Am 17.04.20 um 17:39 schrieb Felix Kuehling: >> Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao: >>> According to the current kiq read register method, there will be >>> race condition when using KIQ to read register if multiple clients >>> want to read at same time just like the expample below: >>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the >>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll >>> the seqno-1 5. the kiq complete these two read operation 6. client-A >>> to read the register at the wb buffer and >>> get REG-1 value >>> >>> Therefore, directly make kiq write the register value at the ring >>> buffer then there will be no race condition for the wb buffer. >>> >>> v2: supply the read_clock and move the reg_val_offs back >>> >>> Signed-off-by: Yintian Tao >>> --- >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 -- >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 - >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++-- >>>drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +--- >>>drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +--- >>>drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28 >>>6 files changed, 33 insertions(+), 40 deletio
Re: [PATCH] drm/amdgpu: refine kiq read register
Hi Monk,
Can we first get the first problem done ?
Please absolutely not! See the problem introduced here is quite worse
than the actual fix.
Previously we ended up with an invalid value in a concurrent register
read, now the KIQs overwrites its own commands and most likely causes a
hang or the hardware to execute something random.
Instead of this crude hack please let us just allocate a fixed number of
write back slots and use them round robin. Then we can make sure that we
don't have more than a fixed number of reads in flight at the same time
as well using the fence values.
This should fix both problems at the same time and not introduce another
potential problematic hack.
If this patch is already committed please revert it immediately.
Regards,
Christian.
Am 20.04.20 um 08:20 schrieb Liu, Monk:
Christian
Well I was under the assumption that this is actually what is done here.
If that is not the case the patch is a rather clear NAK.
<<<
There are two kinds of problems in the current KIQ reading reg, Yintian tend to
fix one of them but not all ...
The first problem is :
During the sleep of the first KIQ reading, another KIQ reading initiated an the
read back register value flushed the first readback value, thus the first
reading will get the wrong result.
This is the issue yintian's patch to address, by put the readback value not in
a shared WB but in a chunk DW of command submit
The second problem is:
Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is busy
with some commands then those unfinished commands maybe overwritten by a new
command submit, and that's not the
Problem yintian's patch tend to address. Felex pointed it out which is fine and
we can use another patch to address it, I'm also planning and scoping it.
The optional way is:
1) We use GPU scheduler to manage KIQ activity, and all jobs are submitted to
KIQ through a IB, thus no overwritten will happen
2) we still skip gpu scheduler but always use IB to put jobs on KIQ, thus each
JOB will occupy the fixed space/DW of RB, so we can avoid overwrite unfinished
command
We can discuss the second problem later
Can we first get the first problem done ? thanks
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Monday, April 20, 2020 1:03 AM
To: Kuehling, Felix ; Tao, Yintian ;
Liu, Monk
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
Am 17.04.20 um 17:39 schrieb Felix Kuehling:
Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao:
According to the current kiq read register method, there will be race
condition when using KIQ to read register if multiple clients want to
read at same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
the seqno-1 5. the kiq complete these two read operation 6. client-A
to read the register at the wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at the ring
buffer then there will be no race condition for the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct
amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
*adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
{
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr &a
RE: [PATCH] drm/amdgpu: refine kiq read register
Christian
>>> Well I was under the assumption that this is actually what is done here.
If that is not the case the patch is a rather clear NAK.
<<<
There are two kinds of problems in the current KIQ reading reg, Yintian tend to
fix one of them but not all ...
The first problem is :
During the sleep of the first KIQ reading, another KIQ reading initiated an the
read back register value flushed the first readback value, thus the first
reading will get the wrong result.
This is the issue yintian's patch to address, by put the readback value not in
a shared WB but in a chunk DW of command submit
The second problem is:
Since we don't utilize GPU scheduler for KIQ submit thus if the KIQ is busy
with some commands then those unfinished commands maybe overwritten by a new
command submit, and that's not the
Problem yintian's patch tend to address. Felex pointed it out which is fine and
we can use another patch to address it, I'm also planning and scoping it.
The optional way is:
1) We use GPU scheduler to manage KIQ activity, and all jobs are submitted to
KIQ through a IB, thus no overwritten will happen
2) we still skip gpu scheduler but always use IB to put jobs on KIQ, thus each
JOB will occupy the fixed space/DW of RB, so we can avoid overwrite unfinished
command
We can discuss the second problem later
Can we first get the first problem done ? thanks
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Monday, April 20, 2020 1:03 AM
To: Kuehling, Felix ; Tao, Yintian
; Liu, Monk
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
Am 17.04.20 um 17:39 schrieb Felix Kuehling:
> Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao:
>> According to the current kiq read register method, there will be race
>> condition when using KIQ to read register if multiple clients want to
>> read at same time just like the expample below:
>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
>> the seqno-1 5. the kiq complete these two read operation 6. client-A
>> to read the register at the wb buffer and
>> get REG-1 value
>>
>> Therefore, directly make kiq write the register value at the ring
>> buffer then there will be no race condition for the wb buffer.
>>
>> v2: supply the read_clock and move the reg_val_offs back
>>
>> Signed-off-by: Yintian Tao
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
>> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
>> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
>> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
>> 6 files changed, 33 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
>> index ea576b4260a4..4e1c0239e561 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
>> @@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct
>> amdgpu_device *adev,
>>
>> spin_lock_init(>ring_lock);
>>
>> -r = amdgpu_device_wb_get(adev, >reg_val_offs);
>> -if (r)
>> -return r;
>> -
>> ring->adev = NULL;
>> ring->ring_obj = NULL;
>> ring->use_doorbell = true;
>> @@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
>> *adev,
>>
>> void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
>> {
>> -amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
>> amdgpu_ring_fini(ring);
>> }
>>
>> @@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
>> uint32_t reg)
>> uint32_t seq;
>> struct amdgpu_kiq *kiq = >gfx.kiq;
>> struct amdgpu_ring *ring = >ring;
>> +uint64_t reg_val_offs = 0;
>>
>> BUG_ON(!ring->funcs->emit_rreg);
>>
>> spin_lock_irqsave(>ring_lock, flags);
>> amdgpu_ring_alloc(ring, 32);
>> -amdgpu_ring_emit_rreg(ring, reg);
>> +reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
> I think that should be (ring->wptr + 30) & ring->buf_mask. Otherwise
> the reg_val_offset can be past the end of the ring.
>
> But that still leaves a problem if another command is submitted to the
> KIQ before you read the returned reg_val fr
RE: [PATCH] drm/amdgpu: refine kiq read register
Hi Felix
Many thanks for your review. I have modified it according to your comments and
suggestion.
Best Regards
Yintian Tao
-Original Message-
From: Kuehling, Felix
Sent: 2020年4月17日 23:39
To: Tao, Yintian ; Liu, Monk
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao:
> According to the current kiq read register method, there will be race
> condition when using KIQ to read register if multiple clients want to
> read at same time just like the expample below:
> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
> the seqno-1 5. the kiq complete these two read operation 6. client-A
> to read the register at the wb buffer and
>get REG-1 value
>
> Therefore, directly make kiq write the register value at the ring
> buffer then there will be no race condition for the wb buffer.
>
> v2: supply the read_clock and move the reg_val_offs back
>
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
> 6 files changed, 33 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index ea576b4260a4..4e1c0239e561 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
> *adev,
>
> spin_lock_init(>ring_lock);
>
> - r = amdgpu_device_wb_get(adev, >reg_val_offs);
> - if (r)
> - return r;
> -
> ring->adev = NULL;
> ring->ring_obj = NULL;
> ring->use_doorbell = true;
> @@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
> *adev,
>
> void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring) {
> - amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
> amdgpu_ring_fini(ring);
> }
>
> @@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
> uint32_t reg)
> uint32_t seq;
> struct amdgpu_kiq *kiq = >gfx.kiq;
> struct amdgpu_ring *ring = >ring;
> + uint64_t reg_val_offs = 0;
>
> BUG_ON(!ring->funcs->emit_rreg);
>
> spin_lock_irqsave(>ring_lock, flags);
> amdgpu_ring_alloc(ring, 32);
> - amdgpu_ring_emit_rreg(ring, reg);
> + reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
I think that should be (ring->wptr + 30) & ring->buf_mask. Otherwise the
reg_val_offset can be past the end of the ring.
But that still leaves a problem if another command is submitted to the KIQ
before you read the returned reg_val from the ring. Your reg_val can be
overwritten by the new command and you get the wrong result. Or the command can
be overwritten with the reg_val, which will most likely hang the CP.
You could allocate space on the KIQ ring with a NOP command to prevent that
space from being overwritten by other commands.
Regards,
Felix
> + amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
> amdgpu_fence_emit_polling(ring, );
> amdgpu_ring_commit(ring);
> spin_unlock_irqrestore(>ring_lock, flags); @@ -707,7 +704,7 @@
> uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
> if (cnt > MAX_KIQ_REG_TRY)
> goto failed_kiq_read;
>
> - return adev->wb.wb[kiq->reg_val_offs];
> + return ring->ring[reg_val_offs];
>
> failed_kiq_read:
> pr_err("failed to read reg:%x\n", reg); diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> index 634746829024..ee698f0246d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> @@ -103,7 +103,6 @@ struct amdgpu_kiq {
> struct amdgpu_ring ring;
> struct amdgpu_irq_src irq;
> const struct kiq_pm4_funcs *pmf;
> - uint32_treg_val_offs;
> };
>
> /*
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index f61664ee4940..a3d88f2aa9f4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -181,7 +181,8 @@ struct amdgpu_ri
Re: [PATCH] drm/amdgpu: refine kiq read register
Am 17.04.20 um 17:39 schrieb Felix Kuehling:
Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao:
According to the current kiq read register method,
there will be race condition when using KIQ to read
register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ
2. client-A poll the seqno-0
3. client-B start to read REG-1 through KIQ
4. client-B poll the seqno-1
5. the kiq complete these two read operation
6. client-A to read the register at the wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at
the ring buffer then there will be no race condition for
the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
{
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
I think that should be (ring->wptr + 30) & ring->buf_mask. Otherwise the
reg_val_offset can be past the end of the ring.
But that still leaves a problem if another command is submitted to the
KIQ before you read the returned reg_val from the ring. Your reg_val can
be overwritten by the new command and you get the wrong result. Or the
command can be overwritten with the reg_val, which will most likely hang
the CP.
You could allocate space on the KIQ ring with a NOP command to prevent
that space from being overwritten by other commands.
Well I was under the assumption that this is actually what is done here.
If that is not the case the patch is a rather clear NAK.
Regards,
Christian.
Regards,
Felix
+ amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
amdgpu_fence_emit_polling(ring, );
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(>ring_lock, flags);
@@ -707,7 +704,7 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
if (cnt > MAX_KIQ_REG_TRY)
goto failed_kiq_read;
- return adev->wb.wb[kiq->reg_val_offs];
+ return ring->ring[reg_val_offs];
failed_kiq_read:
pr_err("failed to read reg:%x\n", reg);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 634746829024..ee698f0246d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -103,7 +103,6 @@ struct amdgpu_kiq {
struct amdgpu_ring ring;
struct amdgpu_irq_src irq;
const struct kiq_pm4_funcs *pmf;
- uint32_treg_val_offs;
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index f61664ee4940..a3d88f2aa9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
- void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
+ void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg,
+ uint64_t reg_val_offs);
void (*emit_wreg)(struct amdgpu_ring *ring, uint32_t reg, uint32_t val);
void (*emit_reg_wait)(struct amdgpu_ring *ring, uint32_t reg,
uint32_t val, uint32_t mask);
@@ -265,7 +266,7 @@ struct
Re: [PATCH] drm/amdgpu: refine kiq read register
Am 2020-04-17 um 2:53 a.m. schrieb Yintian Tao:
> According to the current kiq read register method,
> there will be race condition when using KIQ to read
> register if multiple clients want to read at same time
> just like the expample below:
> 1. client-A start to read REG-0 throguh KIQ
> 2. client-A poll the seqno-0
> 3. client-B start to read REG-1 through KIQ
> 4. client-B poll the seqno-1
> 5. the kiq complete these two read operation
> 6. client-A to read the register at the wb buffer and
>get REG-1 value
>
> Therefore, directly make kiq write the register value at
> the ring buffer then there will be no race condition for
> the wb buffer.
>
> v2: supply the read_clock and move the reg_val_offs back
>
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
> 6 files changed, 33 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index ea576b4260a4..4e1c0239e561 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
>
> spin_lock_init(>ring_lock);
>
> - r = amdgpu_device_wb_get(adev, >reg_val_offs);
> - if (r)
> - return r;
> -
> ring->adev = NULL;
> ring->ring_obj = NULL;
> ring->use_doorbell = true;
> @@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
>
> void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
> {
> - amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
> amdgpu_ring_fini(ring);
> }
>
> @@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
> uint32_t reg)
> uint32_t seq;
> struct amdgpu_kiq *kiq = >gfx.kiq;
> struct amdgpu_ring *ring = >ring;
> + uint64_t reg_val_offs = 0;
>
> BUG_ON(!ring->funcs->emit_rreg);
>
> spin_lock_irqsave(>ring_lock, flags);
> amdgpu_ring_alloc(ring, 32);
> - amdgpu_ring_emit_rreg(ring, reg);
> + reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
I think that should be (ring->wptr + 30) & ring->buf_mask. Otherwise the
reg_val_offset can be past the end of the ring.
But that still leaves a problem if another command is submitted to the
KIQ before you read the returned reg_val from the ring. Your reg_val can
be overwritten by the new command and you get the wrong result. Or the
command can be overwritten with the reg_val, which will most likely hang
the CP.
You could allocate space on the KIQ ring with a NOP command to prevent
that space from being overwritten by other commands.
Regards,
Felix
> + amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
> amdgpu_fence_emit_polling(ring, );
> amdgpu_ring_commit(ring);
> spin_unlock_irqrestore(>ring_lock, flags);
> @@ -707,7 +704,7 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
> uint32_t reg)
> if (cnt > MAX_KIQ_REG_TRY)
> goto failed_kiq_read;
>
> - return adev->wb.wb[kiq->reg_val_offs];
> + return ring->ring[reg_val_offs];
>
> failed_kiq_read:
> pr_err("failed to read reg:%x\n", reg);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> index 634746829024..ee698f0246d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> @@ -103,7 +103,6 @@ struct amdgpu_kiq {
> struct amdgpu_ring ring;
> struct amdgpu_irq_src irq;
> const struct kiq_pm4_funcs *pmf;
> - uint32_treg_val_offs;
> };
>
> /*
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index f61664ee4940..a3d88f2aa9f4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
> void (*end_use)(struct amdgpu_ring *ring);
> void (*emit_switch_buffer) (struct amdgpu_ring *ring);
> void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
> - void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
> + void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg,
> + uint64_t reg_val_offs);
> void (*emit_wreg)(struct amdgpu_ring *ring, uint32_t reg, uint32_t val);
> void (*emit_reg_wait)(struct amdgpu_ring *ring, uint32_t reg,
> uint32_t val, uint32_t mask);
> @@ -265,7 +266,7 @@ struct amdgpu_ring {
> #define amdgpu_ring_emit_hdp_flush(r) (r)->funcs->emit_hdp_flush((r))
RE: [PATCH] drm/amdgpu: refine kiq read register
Hi Christian
Can you help give more details about how this spm trace works
After review the gfx_v9_0_update_spm_vmid function, I think it is some confused.
For example:
It is assumed that there are two gfx job which can be submitted to gfx ring.
When second gfx job is submitted, the vmid of first gfx job write to
mmRLC_SPM_MC_CNTL may be overwritten by the second gfx job vmid.
I am not sure whether it will raise problem.
Best Regards
Yintian Tao
-Original Message-
From: Liu, Monk
Sent: 2020年4月17日 17:40
To: Koenig, Christian ; Tao, Yintian
; Kuehling, Felix ; Deucher,
Alexander ; Zhang, Hawking ;
Ming, Davis ; Jiang, Jerry (SW)
Cc: amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: refine kiq read register
Hi Christian
mmRLC_SPM_MC_CNTL
this register is a RLC register, with my understanding it is PF share
register, and I did experiment proved it:
1) write abc to it in PF
2) read it from VF, it shows abc
3) write ff to it in VF, read it, it is still abc
So this register with current policy (L1) is a VF read, PF write register, and
this register is physically shared among PF/VF
We should not even try to write it in VF side, no matter CPU or KIQ (KIQ write
within VF role will also be blocked by the L1 policy)
From what I can see so far: we need to drop this feature for SRIOV, or we need
to change Policy
+@Ming, Davis and @Jiang, Jerry (SW) for awareness
DRM-NEXT kernel branch has a new feature to massively use KIQ to read/write
this register " mmRLC_SPM_MC_CNTL" which is a PF w/r bug VF R only register.
We need to figure out what should we do on it
I will talk to UMD guys later (they initiated this feature in our kernel driver
) _
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Koenig, Christian
Sent: Friday, April 17, 2020 5:14 PM
To: Liu, Monk ; Tao, Yintian ; Kuehling,
Felix ; Deucher, Alexander ;
Zhang, Hawking
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
> Dynamic alloc each time doing KIQ reg read is a overkill to me
Yeah, that is a rather good argument.
> Now we do KIQ read and write *every time* we do amdgpu_vm_flush
> (omg... what's this ??)
That is updating the VMID used for the SPM trace. And yes this
read/modify/write is most likely not a good idea, we should rather just write
the value we want to have or don't use the KIQ here.
Most likely the later because IIRC this is a per VF register.
Christian.
Am 17.04.20 um 11:06 schrieb Liu, Monk:
> Christian
>
> See we wanted to map the ring buffers read only and USWC for some time.
> That would result in either not working driver or rather crappy performance.
> <<
>
> For KIQ the ring buffer wouldn't be read only ... should be cacheable
> type
>
> Dynamic alloc each time doing KIQ reg read is a overkill to me, leverage ring
> buffer is a high efficient way.
>
> Besides looks now the KIQ register reading is really massive, check this code:
>
> 4949 static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev,
> unsigned vmid)
> 4950 {
> 4951 u32 data;
> 4952
> 4953 data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> 4954
> 4955 data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> 4956 data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> 4957
> 4958 WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
> 4959 }
>
> Now we do KIQ read and write *every time* we do amdgpu_vm_flush
> (omg... what's this ??)
>
>
>
> _
> Monk Liu|GPU Virtualization Team |AMD
>
>
> -Original Message-
> From: Koenig, Christian
> Sent: Friday, April 17, 2020 4:59 PM
> To: Liu, Monk ; Tao, Yintian ;
> Kuehling, Felix ; Deucher, Alexander
> ; Zhang, Hawking
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
>
> Looks like a rather important bug fix to me, but I'm not sure if writing the
> value into the ring buffer is a good idea.
>
> See we wanted to map the ring buffers read only and USWC for some time.
> That would result in either not working driver or rather crappy performance.
>
> Can't we just call amdgpu_device_wb_get() in amdgpu_device_wb_get() instead
> and allocate the wb address dynamically?
>
> Regards,
> Christian.
>
> Am 17.04.20 um 09:01 schrieb Liu, Monk:
>> The change Looks good with me, you can put my RB to your patch .
>>
>> Since this patch impact on general logic (not SRIOV only) I would
>> like you wait a little longer for @Kuehling, Felix and @Deucher,
>> Alexander and @Koenig, Christian @Zhang, Hawking
>>
>> If any of them gave you a RB I think we can go this way
>>
>
RE: [PATCH] drm/amdgpu: refine kiq read register
Hi Christian
mmRLC_SPM_MC_CNTL
this register is a RLC register, with my understanding it is PF share
register, and I did experiment proved it:
1) write abc to it in PF
2) read it from VF, it shows abc
3) write ff to it in VF, read it, it is still abc
So this register with current policy (L1) is a VF read, PF write register, and
this register is physically shared among PF/VF
We should not even try to write it in VF side, no matter CPU or KIQ (KIQ write
within VF role will also be blocked by the L1 policy)
>From what I can see so far: we need to drop this feature for SRIOV, or we need
>to change Policy
+@Ming, Davis and @Jiang, Jerry (SW) for awareness
DRM-NEXT kernel branch has a new feature to massively use KIQ to read/write
this register " mmRLC_SPM_MC_CNTL" which is a PF w/r bug VF R only register.
We need to figure out what should we do on it
I will talk to UMD guys later (they initiated this feature in our kernel driver
)
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Koenig, Christian
Sent: Friday, April 17, 2020 5:14 PM
To: Liu, Monk ; Tao, Yintian ; Kuehling,
Felix ; Deucher, Alexander ;
Zhang, Hawking
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
> Dynamic alloc each time doing KIQ reg read is a overkill to me
Yeah, that is a rather good argument.
> Now we do KIQ read and write *every time* we do amdgpu_vm_flush
> (omg... what's this ??)
That is updating the VMID used for the SPM trace. And yes this
read/modify/write is most likely not a good idea, we should rather just write
the value we want to have or don't use the KIQ here.
Most likely the later because IIRC this is a per VF register.
Christian.
Am 17.04.20 um 11:06 schrieb Liu, Monk:
> Christian
>
> See we wanted to map the ring buffers read only and USWC for some time.
> That would result in either not working driver or rather crappy performance.
> <<
>
> For KIQ the ring buffer wouldn't be read only ... should be cacheable
> type
>
> Dynamic alloc each time doing KIQ reg read is a overkill to me, leverage ring
> buffer is a high efficient way.
>
> Besides looks now the KIQ register reading is really massive, check this code:
>
> 4949 static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev,
> unsigned vmid)
> 4950 {
> 4951 u32 data;
> 4952
> 4953 data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> 4954
> 4955 data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> 4956 data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> 4957
> 4958 WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
> 4959 }
>
> Now we do KIQ read and write *every time* we do amdgpu_vm_flush
> (omg... what's this ??)
>
>
>
> _
> Monk Liu|GPU Virtualization Team |AMD
>
>
> -Original Message-
> From: Koenig, Christian
> Sent: Friday, April 17, 2020 4:59 PM
> To: Liu, Monk ; Tao, Yintian ;
> Kuehling, Felix ; Deucher, Alexander
> ; Zhang, Hawking
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
>
> Looks like a rather important bug fix to me, but I'm not sure if writing the
> value into the ring buffer is a good idea.
>
> See we wanted to map the ring buffers read only and USWC for some time.
> That would result in either not working driver or rather crappy performance.
>
> Can't we just call amdgpu_device_wb_get() in amdgpu_device_wb_get() instead
> and allocate the wb address dynamically?
>
> Regards,
> Christian.
>
> Am 17.04.20 um 09:01 schrieb Liu, Monk:
>> The change Looks good with me, you can put my RB to your patch .
>>
>> Since this patch impact on general logic (not SRIOV only) I would
>> like you wait a little longer for @Kuehling, Felix and @Deucher,
>> Alexander and @Koenig, Christian @Zhang, Hawking
>>
>> If any of them gave you a RB I think we can go this way
>>
>> _____________
>> Monk Liu|GPU Virtualization Team |AMD
>>
>>
>> -Original Message-
>> From: Yintian Tao
>> Sent: Friday, April 17, 2020 2:53 PM
>> To: Liu, Monk
>> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
>> Subject: [PATCH] drm/amdgpu: refine kiq read register
>>
>> According to the current kiq read register method, there will be race
>> condition when using KIQ to read register if multiple clients want to read
>> at same time just like the expample below:
>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
>> client-B start to read REG-1 through KIQ 4. client-B
Re: [PATCH] drm/amdgpu: refine kiq read register
Dynamic alloc each time doing KIQ reg read is a overkill to me
Yeah, that is a rather good argument.
Now we do KIQ read and write *every time* we do amdgpu_vm_flush (omg...
what's this ??)
That is updating the VMID used for the SPM trace. And yes this
read/modify/write is most likely not a good idea, we should rather just
write the value we want to have or don't use the KIQ here.
Most likely the later because IIRC this is a per VF register.
Christian.
Am 17.04.20 um 11:06 schrieb Liu, Monk:
Christian
See we wanted to map the ring buffers read only and USWC for some time.
That would result in either not working driver or rather crappy performance.
<<
For KIQ the ring buffer wouldn't be read only ... should be cacheable type
Dynamic alloc each time doing KIQ reg read is a overkill to me, leverage ring
buffer is a high efficient way.
Besides looks now the KIQ register reading is really massive, check this code:
4949 static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev, unsigned
vmid)
4950 {
4951 u32 data;
4952
4953 data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
4954
4955 data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
4956 data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
4957
4958 WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
4959 }
Now we do KIQ read and write *every time* we do amdgpu_vm_flush (omg...
what's this ??)
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Koenig, Christian
Sent: Friday, April 17, 2020 4:59 PM
To: Liu, Monk ; Tao, Yintian ; Kuehling, Felix
; Deucher, Alexander ; Zhang, Hawking
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
Looks like a rather important bug fix to me, but I'm not sure if writing the
value into the ring buffer is a good idea.
See we wanted to map the ring buffers read only and USWC for some time.
That would result in either not working driver or rather crappy performance.
Can't we just call amdgpu_device_wb_get() in amdgpu_device_wb_get() instead and
allocate the wb address dynamically?
Regards,
Christian.
Am 17.04.20 um 09:01 schrieb Liu, Monk:
The change Looks good with me, you can put my RB to your patch .
Since this patch impact on general logic (not SRIOV only) I would like
you wait a little longer for @Kuehling, Felix and @Deucher, Alexander
and @Koenig, Christian @Zhang, Hawking
If any of them gave you a RB I think we can go this way
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Yintian Tao
Sent: Friday, April 17, 2020 2:53 PM
To: Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq read register
According to the current kiq read register method, there will be race condition
when using KIQ to read register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at the ring buffer then
there will be no race condition for the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
*adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
*adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring) {
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_va
RE: [PATCH] drm/amdgpu: refine kiq read register
Christian
>>
See we wanted to map the ring buffers read only and USWC for some time.
That would result in either not working driver or rather crappy performance.
<<
For KIQ the ring buffer wouldn't be read only ... should be cacheable type
Dynamic alloc each time doing KIQ reg read is a overkill to me, leverage ring
buffer is a high efficient way.
Besides looks now the KIQ register reading is really massive, check this code:
4949 static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev, unsigned
vmid)
4950 {
4951 u32 data;
4952
4953 data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
4954
4955 data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
4956 data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
4957
4958 WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
4959 }
Now we do KIQ read and write *every time* we do amdgpu_vm_flush (omg...
what's this ??)
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Koenig, Christian
Sent: Friday, April 17, 2020 4:59 PM
To: Liu, Monk ; Tao, Yintian ; Kuehling,
Felix ; Deucher, Alexander ;
Zhang, Hawking
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq read register
Looks like a rather important bug fix to me, but I'm not sure if writing the
value into the ring buffer is a good idea.
See we wanted to map the ring buffers read only and USWC for some time.
That would result in either not working driver or rather crappy performance.
Can't we just call amdgpu_device_wb_get() in amdgpu_device_wb_get() instead and
allocate the wb address dynamically?
Regards,
Christian.
Am 17.04.20 um 09:01 schrieb Liu, Monk:
> The change Looks good with me, you can put my RB to your patch .
>
> Since this patch impact on general logic (not SRIOV only) I would like
> you wait a little longer for @Kuehling, Felix and @Deucher, Alexander
> and @Koenig, Christian @Zhang, Hawking
>
> If any of them gave you a RB I think we can go this way
>
> _
> Monk Liu|GPU Virtualization Team |AMD
>
>
> -Original Message-
> From: Yintian Tao
> Sent: Friday, April 17, 2020 2:53 PM
> To: Liu, Monk
> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
> Subject: [PATCH] drm/amdgpu: refine kiq read register
>
> According to the current kiq read register method, there will be race
> condition when using KIQ to read register if multiple clients want to read at
> same time just like the expample below:
> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
> client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
> kiq complete these two read operation 6. client-A to read the register at the
> wb buffer and
> get REG-1 value
>
> Therefore, directly make kiq write the register value at the ring buffer then
> there will be no race condition for the wb buffer.
>
> v2: supply the read_clock and move the reg_val_offs back
>
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
> 6 files changed, 33 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index ea576b4260a4..4e1c0239e561 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
> *adev,
>
> spin_lock_init(>ring_lock);
>
> - r = amdgpu_device_wb_get(adev, >reg_val_offs);
> - if (r)
> - return r;
> -
> ring->adev = NULL;
> ring->ring_obj = NULL;
> ring->use_doorbell = true;
> @@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device
> *adev,
>
> void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring) {
> - amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
> amdgpu_ring_fini(ring);
> }
>
> @@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
> uint32_t reg)
> uint32_t seq;
> struct amdgpu_kiq *kiq = >gfx.kiq;
> struct amdgpu_ring *ring = >ring;
> + uint64_t reg_val_offs = 0;
>
> BUG_ON(!ring->funcs->emit_rreg);
>
> spin_lock_irqsave(>ring_lock, flags);
> amdgpu_ring_alloc(ring, 32);
Re: [PATCH] drm/amdgpu: refine kiq read register
Looks like a rather important bug fix to me, but I'm not sure if writing
the value into the ring buffer is a good idea.
See we wanted to map the ring buffers read only and USWC for some time.
That would result in either not working driver or rather crappy performance.
Can't we just call amdgpu_device_wb_get() in amdgpu_device_wb_get()
instead and allocate the wb address dynamically?
Regards,
Christian.
Am 17.04.20 um 09:01 schrieb Liu, Monk:
The change Looks good with me, you can put my RB to your patch .
Since this patch impact on general logic (not SRIOV only) I would like you wait
a little longer for @Kuehling, Felix and @Deucher, Alexander and @Koenig,
Christian @Zhang, Hawking
If any of them gave you a RB I think we can go this way
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Yintian Tao
Sent: Friday, April 17, 2020 2:53 PM
To: Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq read register
According to the current kiq read register method, there will be race condition
when using KIQ to read register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at the ring buffer then
there will be no race condition for the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring) {
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
+ amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
amdgpu_fence_emit_polling(ring, );
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(>ring_lock, flags); @@ -707,7 +704,7 @@
uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
if (cnt > MAX_KIQ_REG_TRY)
goto failed_kiq_read;
- return adev->wb.wb[kiq->reg_val_offs];
+ return ring->ring[reg_val_offs];
failed_kiq_read:
pr_err("failed to read reg:%x\n", reg); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 634746829024..ee698f0246d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -103,7 +103,6 @@ struct amdgpu_kiq {
struct amdgpu_ring ring;
struct amdgpu_irq_src irq;
const struct kiq_pm4_funcs *pmf;
- uint32_treg_val_offs;
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index f61664ee4940..a3d88f2aa9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
- void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
+ void (*emit_rreg)(struct amdgpu_ring *ring, ui
RE: [PATCH] drm/amdgpu: refine kiq read register
The change Looks good with me, you can put my RB to your patch .
Since this patch impact on general logic (not SRIOV only) I would like you wait
a little longer for @Kuehling, Felix and @Deucher, Alexander and @Koenig,
Christian @Zhang, Hawking
If any of them gave you a RB I think we can go this way
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Yintian Tao
Sent: Friday, April 17, 2020 2:53 PM
To: Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq read register
According to the current kiq read register method, there will be race condition
when using KIQ to read register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at the ring buffer then
there will be no race condition for the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring) {
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
+ amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
amdgpu_fence_emit_polling(ring, );
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(>ring_lock, flags); @@ -707,7 +704,7 @@
uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg)
if (cnt > MAX_KIQ_REG_TRY)
goto failed_kiq_read;
- return adev->wb.wb[kiq->reg_val_offs];
+ return ring->ring[reg_val_offs];
failed_kiq_read:
pr_err("failed to read reg:%x\n", reg); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 634746829024..ee698f0246d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -103,7 +103,6 @@ struct amdgpu_kiq {
struct amdgpu_ring ring;
struct amdgpu_irq_src irq;
const struct kiq_pm4_funcs *pmf;
- uint32_treg_val_offs;
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index f61664ee4940..a3d88f2aa9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
- void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
+ void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg,
+ uint64_t reg_val_offs);
void (*emit_wreg)(struct amdgpu_ring *ring, uint32_t reg, uint32_t val);
void (*emit_reg_wait)(struct amdgpu_ring *ring, uint32_t reg,
uint32_t val, uint32_t mask);
@@ -265,7 +266,7 @@ struct amdgpu_ring { #define amdgpu_ring_emit_hdp_flush(r)
(r)->funcs->emit_hdp_flush((r)) #define amdgpu_ring_emit_switch_buffer(r)
(r)->
[PATCH] drm/amdgpu: refine kiq read register
According to the current kiq read register method,
there will be race condition when using KIQ to read
register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ
2. client-A poll the seqno-0
3. client-B start to read REG-1 through KIQ
4. client-B poll the seqno-1
5. the kiq complete these two read operation
6. client-A to read the register at the wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at
the ring buffer then there will be no race condition for
the wb buffer.
v2: supply the read_clock and move the reg_val_offs back
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 +---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 28
6 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..4e1c0239e561 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
{
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr & ring->buf_mask) + 30;
+ amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
amdgpu_fence_emit_polling(ring, );
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(>ring_lock, flags);
@@ -707,7 +704,7 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
if (cnt > MAX_KIQ_REG_TRY)
goto failed_kiq_read;
- return adev->wb.wb[kiq->reg_val_offs];
+ return ring->ring[reg_val_offs];
failed_kiq_read:
pr_err("failed to read reg:%x\n", reg);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 634746829024..ee698f0246d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -103,7 +103,6 @@ struct amdgpu_kiq {
struct amdgpu_ring ring;
struct amdgpu_irq_src irq;
const struct kiq_pm4_funcs *pmf;
- uint32_treg_val_offs;
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index f61664ee4940..a3d88f2aa9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
- void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
+ void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg,
+ uint64_t reg_val_offs);
void (*emit_wreg)(struct amdgpu_ring *ring, uint32_t reg, uint32_t val);
void (*emit_reg_wait)(struct amdgpu_ring *ring, uint32_t reg,
uint32_t val, uint32_t mask);
@@ -265,7 +266,7 @@ struct amdgpu_ring {
#define amdgpu_ring_emit_hdp_flush(r) (r)->funcs->emit_hdp_flush((r))
#define amdgpu_ring_emit_switch_buffer(r) (r)->funcs->emit_switch_buffer((r))
#define amdgpu_ring_emit_cntxcntl(r, d) (r)->funcs->emit_cntxcntl((r), (d))
-#define amdgpu_ring_emit_rreg(r, d) (r)->funcs->emit_rreg((r), (d))
+#define amdgpu_ring_emit_rreg(r, d, o) (r)->funcs->emit_rreg((r), (d), (o))
#define amdgpu_ring_emit_wreg(r, d, v) (r)->funcs->emit_wreg((r), (d), (v))
#define amdgpu_ring_emit_reg_wait(r, d, v, m) (r)->funcs->emit_reg_wait((r),
(d), (v), (m))
#define amdgpu_ring_emit_reg_write_reg_wait(r, d0, d1, v, m)
(r)->funcs->emit_reg_write_reg_wait((r), (d0), (d1), (v), (m))
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0a03e2ad5d95..7c9a5e440509 100644
---
[PATCH] drm/amdgpu: refine kiq read register
According to the current kiq read register method,
there will be race condition when using KIQ to read
register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ
2. client-A poll the seqno-0
3. client-B start to read REG-1 through KIQ
4. client-B poll the seqno-1
5. the kiq complete these two read operation
6. client-A to read the register at the wb buffer and
get REG-1 value
Therefore, directly make kiq write the register value at
the ring buffer then there will be no race condition for
the wb buffer.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 11 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 11 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 12 ++--
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 25
6 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index ea576b4260a4..1253dd1ba42c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -304,10 +304,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
spin_lock_init(>ring_lock);
- r = amdgpu_device_wb_get(adev, >reg_val_offs);
- if (r)
- return r;
-
ring->adev = NULL;
ring->ring_obj = NULL;
ring->use_doorbell = true;
@@ -331,7 +327,6 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
void amdgpu_gfx_kiq_free_ring(struct amdgpu_ring *ring)
{
- amdgpu_device_wb_free(ring->adev, ring->adev->gfx.kiq.reg_val_offs);
amdgpu_ring_fini(ring);
}
@@ -675,12 +670,14 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
uint32_t seq;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *ring = >ring;
+ uint64_t reg_val_offs = 0;
BUG_ON(!ring->funcs->emit_rreg);
spin_lock_irqsave(>ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
- amdgpu_ring_emit_rreg(ring, reg);
+ reg_val_offs = (ring->wptr & ring->buf_mask) + 16;
+ amdgpu_ring_emit_rreg(ring, reg, reg_val_offs);
amdgpu_fence_emit_polling(ring, );
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(>ring_lock, flags);
@@ -707,7 +704,7 @@ uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev,
uint32_t reg)
if (cnt > MAX_KIQ_REG_TRY)
goto failed_kiq_read;
- return adev->wb.wb[kiq->reg_val_offs];
+ return ring->ring[reg_val_offs];
failed_kiq_read:
pr_err("failed to read reg:%x\n", reg);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 634746829024..ee698f0246d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -103,7 +103,6 @@ struct amdgpu_kiq {
struct amdgpu_ring ring;
struct amdgpu_irq_src irq;
const struct kiq_pm4_funcs *pmf;
- uint32_treg_val_offs;
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index f61664ee4940..a3d88f2aa9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -181,7 +181,8 @@ struct amdgpu_ring_funcs {
void (*end_use)(struct amdgpu_ring *ring);
void (*emit_switch_buffer) (struct amdgpu_ring *ring);
void (*emit_cntxcntl) (struct amdgpu_ring *ring, uint32_t flags);
- void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg);
+ void (*emit_rreg)(struct amdgpu_ring *ring, uint32_t reg,
+ uint64_t reg_val_offs);
void (*emit_wreg)(struct amdgpu_ring *ring, uint32_t reg, uint32_t val);
void (*emit_reg_wait)(struct amdgpu_ring *ring, uint32_t reg,
uint32_t val, uint32_t mask);
@@ -265,7 +266,7 @@ struct amdgpu_ring {
#define amdgpu_ring_emit_hdp_flush(r) (r)->funcs->emit_hdp_flush((r))
#define amdgpu_ring_emit_switch_buffer(r) (r)->funcs->emit_switch_buffer((r))
#define amdgpu_ring_emit_cntxcntl(r, d) (r)->funcs->emit_cntxcntl((r), (d))
-#define amdgpu_ring_emit_rreg(r, d) (r)->funcs->emit_rreg((r), (d))
+#define amdgpu_ring_emit_rreg(r, d, o) (r)->funcs->emit_rreg((r), (d), (o))
#define amdgpu_ring_emit_wreg(r, d, v) (r)->funcs->emit_wreg((r), (d), (v))
#define amdgpu_ring_emit_reg_wait(r, d, v, m) (r)->funcs->emit_reg_wait((r),
(d), (v), (m))
#define amdgpu_ring_emit_reg_write_reg_wait(r, d0, d1, v, m)
(r)->funcs->emit_reg_write_reg_wait((r), (d0), (d1), (v), (m))
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0a03e2ad5d95..5873e56341f3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++
