Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
The usage is that UMDs will no longer have to wait for idle at the end of IBs. If you have WAIT_REG_MEM or PS/CS_PARTIAL_FLUSH at the end of IBs, you can remove that. The responsibility to sync is taken over by the kernel driver. This has a potential to increase performance for fullscreen applications, because the kernel will sync only when the sync is required for inter-process sharing, which is never for fullscreen apps. Also if 2 or more windowed apps are rendering, there will be no longer any sync when switching from one process to the next in the gfx ring. The sync will only happen before the compositor starts drawing the fullscreen frame. Therefore, the windowed apps running in parallel should run faster. If the UMD syncs at the beginning of IBs (common e.g. with DCC fast clear), there will be no improvement in performance. For any improvement to be there, UMDs shouldn't sync at the beginning of IBs either, but this may not always be possible. (a fast color clear needs a sync, while a fast Z/S clear doesn't) Marek On Thu, Jun 11, 2020 at 8:13 AM Chunming Zhou wrote: > I didn't check the patch details, if it is for existing implicit sync of > shared buffer, feel free go ahead. > > But if you add some description for its usage, that will be more clear to > others. > > -David > 在 2020/6/11 15:19, Marek Olšák 写道: > > Hi David, > > Explicit sync has nothing to do with this. This is for implicit sync, > which is required by DRI3. This fix allows removing existing inefficiencies > from drivers, so it's a good thing. > > Marek > > On Wed., Jun. 10, 2020, 03:56 Chunming Zhou, wrote: > >> >> 在 2020/6/10 15:41, Christian König 写道: >> >> That's true, but for now we are stuck with the implicit sync for quite a >> number of use cases. >> >> My problem is rather that we already tried this and it backfired >> immediately. >> >> I do remember that it was your patch who introduced the pipeline sync >> flag handling and I warned that this could be problematic. You then came >> back with a QA result saying that this is indeed causing a huge performance >> drop in one test case and we need to do something else. Together we then >> came up with the different handling between implicit and explicit sync. >> >> Isn't pipeline sync flag to fix some issue because of parralel execution >> between jobs in one pipeline? I really don't have this memory in mind why >> that's realted to this, Or do you mean extra sync hides many other >> potential issues? >> >> Anyway, when I go through Vulkan WSI code, the synchronization isn't so >> smooth between OS window system. And when I saw Jason drives explicit sync >> through the whole Linux ecosystem like Android window system does, I feel >> that's really a good direction. >> >> -David >> >> >> But I can't find that stupid mail thread any more. I knew that it was a >> couple of years ago when we started with the explicit sync for Vulkan. >> >> Christian. >> >> Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): >> >> [AMD Official Use Only - Internal Distribution Only] >> >> >> >> Not sue if this is right direction, I think usermode wants all >> synchronizations to be explicit. Implicit sync often confuses people who >> don’t know its history. I remember Jason from Intel is driving explicit >> synchronization through the Linux ecosystem, which even removes implicit >> sync of shared buffer. >> >> >> >> -David >> >> >> >> *From:* amd-gfx >> *On Behalf Of *Marek Olšák >> *Sent:* Tuesday, June 9, 2020 6:58 PM >> *To:* amd-gfx mailing list >> >> *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and >> implicit sync (v2) >> >> >> >> Hi, >> >> >> >> This enables a full pipeline sync for implicit sync. It's Christian's >> patch with the driver version bumped. With this, user mode drivers don't >> have to wait for idle at the end of gfx IBs. >> >> >> >> Any concerns? >> >> >> >> Thanks, >> >> Marek >> >> ___ >> amd-gfx mailing >> listamd-gfx@lists.freedesktop.orghttps://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%7CDavid1.Zhou%40amd.com%7C0d3096fc043f4443f14e08d80dd7c674%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637274567683552668&sdata=xIHDswGRsdCP%2BE7MRI4nKXdoMgV2LBzFPP46zGpQusk%3D&reserved=0> >> >> >> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
My only concern is that this becomes UAPI as soon as we increase the minor number. So if we find that this has some negative side effects we can never go back again. But the choice is up to you guys, from my side it is perfectly good to go. Christian. Am 11.06.20 um 14:13 schrieb Chunming Zhou: I didn't check the patch details, if it is for existing implicit sync of shared buffer, feel free go ahead. But if you add some description for its usage, that will be more clear to others. -David 在 2020/6/11 15:19, Marek Olšák 写道: Hi David, Explicit sync has nothing to do with this. This is for implicit sync, which is required by DRI3. This fix allows removing existing inefficiencies from drivers, so it's a good thing. Marek On Wed., Jun. 10, 2020, 03:56 Chunming Zhou, <mailto:zhou...@amd.com>> wrote: 在 2020/6/10 15:41, Christian König 写道: That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag handling and I warned that this could be problematic. You then came back with a QA result saying that this is indeed causing a huge performance drop in one test case and we need to do something else. Together we then came up with the different handling between implicit and explicit sync. Isn't pipeline sync flag to fix some issue because of parralel execution between jobs in one pipeline? I really don't have this memory in mind why that's realted to this, Or do you mean extra sync hides many other potential issues? Anyway, when I go through Vulkan WSI code, the synchronization isn't so smooth between OS window system. And when I saw Jason drives explicit sync through the whole Linux ecosystem like Android window system does, I feel that's really a good direction. -David But I can't find that stupid mail thread any more. I knew that it was a couple of years ago when we started with the explicit sync for Vulkan. Christian. Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): [AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don’t know its history. I remember Jason from Intel is driving explicit synchronization through the Linux ecosystem, which even removes implicit sync of shared buffer. -David *From:* amd-gfx <mailto:amd-gfx-boun...@lists.freedesktop.org> *On Behalf Of *Marek Olšák *Sent:* Tuesday, June 9, 2020 6:58 PM *To:* amd-gfx mailing list <mailto:amd-gfx@lists.freedesktop.org> *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2) Hi, This enables a full pipeline sync for implicit sync. It's Christian's patch with the driver version bumped. With this, user mode drivers don't have to wait for idle at the end of gfx IBs. Any concerns? Thanks, Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org> 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%7CDavid1.Zhou%40amd.com%7C0d3096fc043f4443f14e08d80dd7c674%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637274567683552668&sdata=xIHDswGRsdCP%2BE7MRI4nKXdoMgV2LBzFPP46zGpQusk%3D&reserved=0> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
I didn't check the patch details, if it is for existing implicit sync of shared buffer, feel free go ahead. But if you add some description for its usage, that will be more clear to others. -David 在 2020/6/11 15:19, Marek Olšák 写道: Hi David, Explicit sync has nothing to do with this. This is for implicit sync, which is required by DRI3. This fix allows removing existing inefficiencies from drivers, so it's a good thing. Marek On Wed., Jun. 10, 2020, 03:56 Chunming Zhou, <mailto:zhou...@amd.com>> wrote: 在 2020/6/10 15:41, Christian König 写道: That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag handling and I warned that this could be problematic. You then came back with a QA result saying that this is indeed causing a huge performance drop in one test case and we need to do something else. Together we then came up with the different handling between implicit and explicit sync. Isn't pipeline sync flag to fix some issue because of parralel execution between jobs in one pipeline? I really don't have this memory in mind why that's realted to this, Or do you mean extra sync hides many other potential issues? Anyway, when I go through Vulkan WSI code, the synchronization isn't so smooth between OS window system. And when I saw Jason drives explicit sync through the whole Linux ecosystem like Android window system does, I feel that's really a good direction. -David But I can't find that stupid mail thread any more. I knew that it was a couple of years ago when we started with the explicit sync for Vulkan. Christian. Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): [AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don’t know its history. I remember Jason from Intel is driving explicit synchronization through the Linux ecosystem, which even removes implicit sync of shared buffer. -David *From:* amd-gfx <mailto:amd-gfx-boun...@lists.freedesktop.org> *On Behalf Of *Marek Olšák *Sent:* Tuesday, June 9, 2020 6:58 PM *To:* amd-gfx mailing list <mailto:amd-gfx@lists.freedesktop.org> *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2) Hi, This enables a full pipeline sync for implicit sync. It's Christian's patch with the driver version bumped. With this, user mode drivers don't have to wait for idle at the end of gfx IBs. Any concerns? Thanks, Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org> 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%7CDavid1.Zhou%40amd.com%7C0d3096fc043f4443f14e08d80dd7c674%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637274567683552668&sdata=xIHDswGRsdCP%2BE7MRI4nKXdoMgV2LBzFPP46zGpQusk%3D&reserved=0> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
Hi David, Explicit sync has nothing to do with this. This is for implicit sync, which is required by DRI3. This fix allows removing existing inefficiencies from drivers, so it's a good thing. Marek On Wed., Jun. 10, 2020, 03:56 Chunming Zhou, wrote: > > 在 2020/6/10 15:41, Christian König 写道: > > That's true, but for now we are stuck with the implicit sync for quite a > number of use cases. > > My problem is rather that we already tried this and it backfired > immediately. > > I do remember that it was your patch who introduced the pipeline sync flag > handling and I warned that this could be problematic. You then came back > with a QA result saying that this is indeed causing a huge performance drop > in one test case and we need to do something else. Together we then came up > with the different handling between implicit and explicit sync. > > Isn't pipeline sync flag to fix some issue because of parralel execution > between jobs in one pipeline? I really don't have this memory in mind why > that's realted to this, Or do you mean extra sync hides many other > potential issues? > > Anyway, when I go through Vulkan WSI code, the synchronization isn't so > smooth between OS window system. And when I saw Jason drives explicit sync > through the whole Linux ecosystem like Android window system does, I feel > that's really a good direction. > > -David > > > But I can't find that stupid mail thread any more. I knew that it was a > couple of years ago when we started with the explicit sync for Vulkan. > > Christian. > > Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): > > [AMD Official Use Only - Internal Distribution Only] > > > > Not sue if this is right direction, I think usermode wants all > synchronizations to be explicit. Implicit sync often confuses people who > don’t know its history. I remember Jason from Intel is driving explicit > synchronization through the Linux ecosystem, which even removes implicit > sync of shared buffer. > > > > -David > > > > *From:* amd-gfx > *On Behalf Of *Marek Olšák > *Sent:* Tuesday, June 9, 2020 6:58 PM > *To:* amd-gfx mailing list > > *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and > implicit sync (v2) > > > > Hi, > > > > This enables a full pipeline sync for implicit sync. It's Christian's > patch with the driver version bumped. With this, user mode drivers don't > have to wait for idle at the end of gfx IBs. > > > > Any concerns? > > > > Thanks, > > Marek > > ___ > amd-gfx mailing > listamd-gfx@lists.freedesktop.orghttps://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%7CDavid1.Zhou%40amd.com%7C47e97eb8e3654708f7ff08d80d11bcf7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637273717119277965&sdata=EFq2J33HIOiIS3bok2ZcIz%2FhE%2FVs9T0HPy0UFi92Nf4%3D&reserved=0> > > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
在 2020/6/10 15:41, Christian König 写道: That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag handling and I warned that this could be problematic. You then came back with a QA result saying that this is indeed causing a huge performance drop in one test case and we need to do something else. Together we then came up with the different handling between implicit and explicit sync. Isn't pipeline sync flag to fix some issue because of parralel execution between jobs in one pipeline? I really don't have this memory in mind why that's realted to this, Or do you mean extra sync hides many other potential issues? Anyway, when I go through Vulkan WSI code, the synchronization isn't so smooth between OS window system. And when I saw Jason drives explicit sync through the whole Linux ecosystem like Android window system does, I feel that's really a good direction. -David But I can't find that stupid mail thread any more. I knew that it was a couple of years ago when we started with the explicit sync for Vulkan. Christian. Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): [AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don’t know its history. I remember Jason from Intel is driving explicit synchronization through the Linux ecosystem, which even removes implicit sync of shared buffer. -David *From:* amd-gfx *On Behalf Of *Marek Olšák *Sent:* Tuesday, June 9, 2020 6:58 PM *To:* amd-gfx mailing list *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2) Hi, This enables a full pipeline sync for implicit sync. It's Christian's patch with the driver version bumped. With this, user mode drivers don't have to wait for idle at the end of gfx IBs. Any concerns? Thanks, Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag handling and I warned that this could be problematic. You then came back with a QA result saying that this is indeed causing a huge performance drop in one test case and we need to do something else. Together we then came up with the different handling between implicit and explicit sync. But I can't find that stupid mail thread any more. I knew that it was a couple of years ago when we started with the explicit sync for Vulkan. Christian. Am 10.06.20 um 08:29 schrieb Zhou, David(ChunMing): [AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don’t know its history. I remember Jason from Intel is driving explicit synchronization through the Linux ecosystem, which even removes implicit sync of shared buffer. -David *From:* amd-gfx *On Behalf Of *Marek Olšák *Sent:* Tuesday, June 9, 2020 6:58 PM *To:* amd-gfx mailing list *Subject:* [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2) Hi, This enables a full pipeline sync for implicit sync. It's Christian's patch with the driver version bumped. With this, user mode drivers don't have to wait for idle at the end of gfx IBs. Any concerns? Thanks, Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
[AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don't know its history. I remember Jason from Intel is driving explicit synchronization through the Linux ecosystem, which even removes implicit sync of shared buffer. -David From: amd-gfx On Behalf Of Marek Olšák Sent: Tuesday, June 9, 2020 6:58 PM To: amd-gfx mailing list Subject: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2) Hi, This enables a full pipeline sync for implicit sync. It's Christian's patch with the driver version bumped. With this, user mode drivers don't have to wait for idle at the end of gfx IBs. Any concerns? Thanks, Marek ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
Hi,
This enables a full pipeline sync for implicit sync. It's Christian's patch
with the driver version bumped. With this, user mode drivers don't have to
wait for idle at the end of gfx IBs.
Any concerns?
Thanks,
Marek
From 2216e2db0994f1fdeb74353bd669f8981280188e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?=
Date: Wed, 27 May 2020 10:31:08 +0200
Subject: [PATCH] drm/amdgpu: remove distinction between explicit and implicit
sync (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
According to Marek a pipeline sync should be inserted for implicit syncs well.
v2: bump the driver version
Signed-off-by: Christian König
Tested-by: Marek Olšák
Signed-off-by: Marek Olšák
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 12 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 15 -
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 31 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +-
9 files changed, 33 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 68e6e1bc8f3a..c408936e8f98 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -395,7 +395,7 @@ static int vm_update_pds(struct amdgpu_vm *vm, struct amdgpu_sync *sync)
if (ret)
return ret;
- return amdgpu_sync_fence(sync, vm->last_update, false);
+ return amdgpu_sync_fence(sync, vm->last_update);
}
static uint64_t get_pte_flags(struct amdgpu_device *adev, struct kgd_mem *mem)
@@ -785,7 +785,7 @@ static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
amdgpu_vm_clear_freed(adev, vm, &bo_va->last_pt_update);
- amdgpu_sync_fence(sync, bo_va->last_pt_update, false);
+ amdgpu_sync_fence(sync, bo_va->last_pt_update);
return 0;
}
@@ -804,7 +804,7 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
return ret;
}
- return amdgpu_sync_fence(sync, bo_va->last_pt_update, false);
+ return amdgpu_sync_fence(sync, bo_va->last_pt_update);
}
static int map_bo_to_gpuvm(struct amdgpu_device *adev,
@@ -2102,7 +2102,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info, struct dma_fence **ef)
pr_debug("Memory eviction: Validate BOs failed. Try again\n");
goto validate_map_fail;
}
- ret = amdgpu_sync_fence(&sync_obj, bo->tbo.moving, false);
+ ret = amdgpu_sync_fence(&sync_obj, bo->tbo.moving);
if (ret) {
pr_debug("Memory eviction: Sync BO fence failed. Try again\n");
goto validate_map_fail;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 19070226a945..ffbcaf4bfb8b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -992,7 +992,7 @@ static int amdgpu_cs_process_fence_dep(struct amdgpu_cs_parser *p,
dma_fence_put(old);
}
- r = amdgpu_sync_fence(&p->job->sync, fence, true);
+ r = amdgpu_sync_fence(&p->job->sync, fence);
dma_fence_put(fence);
if (r)
return r;
@@ -1014,7 +1014,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
return r;
}
- r = amdgpu_sync_fence(&p->job->sync, fence, true);
+ r = amdgpu_sync_fence(&p->job->sync, fence);
dma_fence_put(fence);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 499ddb0c75d2..a4576a81794a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -87,9 +87,10 @@
* - 3.36.0 - Allow reading more status registers on si/cik
* - 3.37.0 - L2 is invalidated before SDMA IBs, needed for correctness
* - 3.38.0 - Add AMDGPU_IB_FLAG_EMIT_MEM_SYNC
+ * - 3.39.0 - DMABUF implicit sync does a full pipeline sync
*/
#define KMS_DRIVER_MAJOR 3
-#define KMS_DRIVER_MINOR 38
+#define KMS_DRIVER_MINOR 39
#define KMS_DRIVER_PATCHLEVEL 0
int amdgpu_vram_limit = 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index b91853fd66d3..4ffc32b78745 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -178,7 +178,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
need_ctx_switch = ring->current_ctx != fence_ctx;
if (ring->funcs->emit_pipeline_sync && job &&
- ((tmp = amdgpu_sync_get_fence(&job->sched_sync, NULL)) ||
+ ((tmp = amdgpu_sync_get_fence(&job->sched_sync)) ||
(amdgpu_sriov_vf(adev) &
