[PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)
Christian König
ckoenig.leichtzumerken at gmail.com
Fri Jun 12 11:20:04 UTC 2020
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, <zhoucm1 at amd.com
>> <mailto: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>
>>>> <mailto: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>
>>>> <mailto: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 list
>>>> amd-gfx at lists.freedesktop.org <mailto:amd-gfx at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200612/05754901/attachment-0001.htm>
More information about the amd-gfx
mailing list