On Tue, Feb 4, 2025 at 8:37 AM Christian König <christian.koenig@xxxxxxx> wrote: > > Hi Friedrich, > > adding Alex. > > Am 04.02.25 um 13:32 schrieb Friedrich Vock: > > Hi, > > > > On 19.08.24 13:21, Christian König wrote: > >> Am 19.08.24 um 09:21 schrieb Friedrich Vock: > >>> In Vulkan, it is the application's responsibility to perform adequate > >>> synchronization before a sparse unmap, replace or BO destroy operation. > >>> This adds an option to AMDGPU_VA_OPs to disable redundant implicit sync > >>> that happens on sparse unmap or replace operations. > >>> > >>> This has seen a significant improvement in stutter in Forza Horizon 5 > >>> and Forza Horizon 4. (As games that had significant issues in sparse > >>> binding related stutter). > >> > >> Looks pretty good, I have Shashank and his team working on the similar > >> patches ever since Bas initially came up with it since we need it for > >> user queues as well. > >> > >> Shashank can you take a look at the UAPI? Of hand looks pretty similar > >> to what we have done as well, doesn't it? > >> > >> For the internal implementation in the VM I'm currently working on a bug > >> fix for the KFD team, so this is subject to change anyway. Going to keep > >> this requirement here in mind while doing that, whatever implementation > >> we end up with we probably need to re-base it anyway. > > > > Bumping this again - it's been quite a while, what became of that KFD > > bugfix and the userqueue stuff? It'd be nice to finally make progress > > here, whether it's using the user queue interface you worked on or a > > re-spin of this. Maybe it's possible to split this off from the rest of > > the userqueue stuff and merge it beforehand if you're reasonably certain > > about how the uapi should look? Let me know. > > That is merged into amd-staging-drm-next for quite a while now, but we > only defined the interface and dropped all optimizations to initially > get it upstream. > > @Alex IIRC we pushed the KFD part upstream already, but the userqueue > part is still waiting for the final firmware release, right? Correct. Alex > > Regards, > Christian. > > > > > Thanks, > > Friedrich > > > >> > >> Regards, > >> Christian. > >> > >>> > >>> Userspace changes for this new version can be found at [1][2], and a > >>> kernel > >>> branch containing these patches can be found at [3]. > >>> > >>> [1] https://gitlab.freedesktop.org/pixelcluster/drm/-/commits/vm- > >>> explicit-sync > >>> [2] https://gitlab.freedesktop.org/pixelcluster/mesa/-/commits/vm- > >>> explicit-sync > >>> [3] https://gitlab.freedesktop.org/pixelcluster/linux/-/commits/ > >>> amdgpu-vm-explicit-sync > >>> > >>> v3 changes: > >>> - Rebased onto current amd-staging-drm-next > >>> - Added option to wait for drm_syncobjs instead of executing > >>> immediately > >>> > >>> Tatsuyuki Ishi (3): > >>> drm/amdgpu: Don't implicit sync PRT maps. > >>> drm/amdgpu: Add optional explicit sync fences for GEM operations. > >>> drm/amdgpu: Bump amdgpu driver version. > >>> > >>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 76 > >>> ++++++++++++++++--- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 23 +++++- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 6 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c | 2 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 68 +++++++++++------ > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 30 ++++---- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c | 12 ++- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 2 +- > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 9 +++ > >>> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 18 ++--- > >>> include/uapi/drm/amdgpu_drm.h | 7 ++ > >>> 14 files changed, 194 insertions(+), 66 deletions(-) > >>> > >>> -- > >>> 2.46.0 > >>> > > >
