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

Marek Olšák maraeo at gmail.com
Fri Jun 12 22:29:34 UTC 2020


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 at amd.com> 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 at 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 <amd-gfx-bounces at lists.freedesktop.org>
>> <amd-gfx-bounces at lists.freedesktop.org> *On Behalf Of *Marek Olšák
>> *Sent:* Tuesday, June 9, 2020 6:58 PM
>> *To:* amd-gfx mailing list <amd-gfx at lists.freedesktop.org>
>> <amd-gfx at 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 listamd-gfx at 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>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200612/ff408853/attachment-0001.htm>


More information about the amd-gfx mailing list