Monk needs to answer this, but I don't think that this will work.
This explanation even sounds like only one VF can use the feature at the
same time, is that correct?
Regards,
Christian.
Am 20.04.20 um 14:08 schrieb Tao, Yintian:
Hi Monk, Christian
According to the discussion with Jacob offline, UMD will only enable
SPM feature when testing RGP.
And under virtualization , only pp_one_vfmode can test RGP.
Therefore, whether we can directly use MMIO to READ/WRITE register for
RLC_SPM_MC_CNTL?
Best Regards
Yintian Tao
*From:*amd-gfx <[email protected]> *On Behalf Of
*Liu, Monk
*Sent:* 2020年4月20日16:33
*To:* Koenig, Christian <[email protected]>; He, Jacob
<[email protected]>
*Cc:* [email protected]
*Subject:* RE: why we need to do infinite RLC_SPM register setting
during VM flush
Christian
What we want to do is like:
Read reg value from RLC_SPM_MC_CNTL to tmp
Set bits:3:0 to VMID to tmp
Write tmp to RLC_SPM_MC_CNTL
I didn’t find any PM4 packet on GFX9/10 can achieve above goal ….
_____________________________________
Monk Liu|GPU Virtualization Team |AMD
sig-cloud-gpu
*From:*Christian König <[email protected]
<mailto:[email protected]>>
*Sent:* Monday, April 20, 2020 4:03 PM
*To:* Liu, Monk <[email protected] <mailto:[email protected]>>; He,
Jacob <[email protected] <mailto:[email protected]>>; Koenig, Christian
<[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: why we need to do infinite RLC_SPM register setting
during VM flush
I would also prefer to update the SPM VMID register using PM4 packets
instead of the current handling.
Regards,
Christian.
Am 20.04.20 um 09:50 schrieb Liu, Monk:
I just try to explain what I want to do here, no real patch
formalized yet
_____________________________________
Monk Liu|GPU Virtualization Team |AMD
sig-cloud-gpu
*From:*He, Jacob <[email protected]> <mailto:[email protected]>
*Sent:* Monday, April 20, 2020 3:45 PM
*To:* Liu, Monk <[email protected]> <mailto:[email protected]>;
Koenig, Christian <[email protected]>
<mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
*Subject:* Re: why we need to do infinite RLC_SPM register setting
during VM flush
[AMD Official Use Only - Internal Distribution Only]
Do you miss a file which adds spm_updatedto vm structure?
------------------------------------------------------------------------
*From:*Liu, Monk <[email protected] <mailto:[email protected]>>
*Sent:* Monday, April 20, 2020 3:32 PM
*To:* He, Jacob <[email protected] <mailto:[email protected]>>;
Koenig, Christian <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected]
<mailto:[email protected]>
<[email protected] <mailto:[email protected]>>
*Subject:* why we need to do infinite RLC_SPM register setting
during VM flush
Hi Jaco & Christian
As titled , check below patch:
commit 10790a09ea584cc832353a5c2a481012e5e31a13
Author: Jacob He <[email protected] <mailto:[email protected]>>
Date: Fri Feb 28 20:24:41 2020 +0800
drm/amdgpu: Update SPM_VMID with the job's vmid when
application reserves the vmid
SPM access the video memory according to SPM_VMID. It should
be updated
with the job's vmid right before the job is scheduled.
SPM_VMID is a
global resource
Change-Id: Id3881908960398f87e7c95026a54ff83ff826700
Signed-off-by: Jacob He <[email protected] <mailto:[email protected]>>
Reviewed-by: Christian König <[email protected]
<mailto:[email protected]>>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6e6fc8c..ba2236a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1056,8 +1056,12 @@ int amdgpu_vm_flush(struct amdgpu_ring
*ring, struct amdgpu_job *job,
struct dma_fence *fence = NULL;
bool pasid_mapping_needed = false;
unsigned patch_offset = 0;
+ bool update_spm_vmid_needed = (job->vm &&
(job->vm->reserved_vmid[vmhub] != NULL));
int r;
+ if (update_spm_vmid_needed &&
adev->gfx.rlc.funcs->update_spm_vmid)
+ adev->gfx.rlc.funcs->update_spm_vmid(adev, job->vmid);
+
if (amdgpu_vmid_had_gpu_reset(adev, id)) {
gds_switch_needed = true;
vm_flush_needed = true;
this update_spm_vmid() looks an completely overkill to me, we only
need to do it once for its VM …
in SRIOV the register reading/writing for update_spm_vmid() is now
carried by KIQ thus there is too much burden on KIQ for such
unnecessary jobs …
I want to change it to only do it once per VM, like:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6e6fc8c..ba2236a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1056,8 +1056,12 @@ int amdgpu_vm_flush(struct amdgpu_ring
*ring, struct amdgpu_job *job,
struct dma_fence *fence = NULL;
bool pasid_mapping_needed = false;
unsigned patch_offset = 0;
+ bool update_spm_vmid_needed = (job->vm &&
(job->vm->reserved_vmid[vmhub] != NULL));
int r;
+ if (update_spm_vmid_needed &&
adev->gfx.rlc.funcs->update_spm_vmid && !vm->spm_updated) {
+ adev->gfx.rlc.funcs->update_spm_vmid(adev, job->vmid);
+ vm->spm_updated = true;
+ }
if (amdgpu_vmid_had_gpu_reset(adev, id)) {
gds_switch_needed = true;
vm_flush_needed = true;
what do you think ?
P.S.: the best way is to let GFX ring itself to do the
update_spm_vmid() instead of let CPU doing it, e.g.: we put more
PM4 command in VM-FLUSH packets ….
But I prefer the simple way first like I demonstrated above
_____________________________________
Monk Liu|GPU Virtualization Team |AMD
sig-cloud-gpu
_______________________________________________
amd-gfx mailing list
[email protected] <mailto:[email protected]>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cyintian.tao%40amd.com%7C94ed105b251d4c2629cc08d7e5056f39%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637229683834893085&sdata=IJiVlGsX0rL0%2FcTvlSWquG%2F3aufz9R%2FvMlkk%2BpVaQSM%3D&reserved=0>
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
