Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <zhoucm1@xxxxxxx> 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, <zhoucm1@xxxxxxx> 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 <amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Marek Olšák
Sent: Tuesday, June 9, 2020 6:58 PM
To: amd-gfx mailing list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux