drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too

Chunming Zhou zhoucm1 at amd.com
Tue Apr 28 03:22:29 UTC 2020


Yes, same question.

In fact, PAL cmd stream has itself Relase/Acquire packets. That we use 
the flag is per your request.

-David

在 2020/4/27 22:53, Christian König 写道:
> Yeah, but is Mesa going to use it?
>
> Christian.
>
> Am 27.04.20 um 15:54 schrieb Marek Olšák:
>> PAL requested it and they are going to use it. (it looks like they 
>> have to use it for correctness)
>>
>> Marek
>>
>> On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander 
>> <Alexander.Deucher at amd.com <mailto:Alexander.Deucher at amd.com>> wrote:
>>
>>     [AMD Official Use Only - Internal Distribution Only]
>>
>>
>>     Do we have open source code UMD code which uses this?
>>
>>     Alex
>>     ------------------------------------------------------------------------
>>     *From:* Christian König <ckoenig.leichtzumerken at gmail.com
>>     <mailto:ckoenig.leichtzumerken at gmail.com>>
>>     *Sent:* Sunday, April 26, 2020 4:55 AM
>>     *To:* Marek Olšák <maraeo at gmail.com <mailto:maraeo at gmail.com>>;
>>     Koenig, Christian <Christian.Koenig at amd.com
>>     <mailto:Christian.Koenig at amd.com>>
>>     *Cc:* Deucher, Alexander <Alexander.Deucher at amd.com
>>     <mailto:Alexander.Deucher at amd.com>>; amd-gfx mailing list
>>     <amd-gfx at lists.freedesktop.org
>>     <mailto:amd-gfx at lists.freedesktop.org>>
>>     *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to
>>     compute IBs too
>>     Thanks for that explanation. I suspected that there was a good
>>     reason to have that in the kernel, but couldn't find one.
>>
>>     In this case the patch is Reviewed-by: Christian König
>>     <christian.koenig at amd.com> <mailto:christian.koenig at amd.com>
>>
>>     We should probably add this explanation as comment to the flag as
>>     well.
>>
>>     Thanks,
>>     Christian.
>>
>>     Am 26.04.20 um 02:43 schrieb Marek Olšák:
>>>     It was merged into amd-staging-drm-next.
>>>
>>>     I'm not absolutely sure, but I think we need to invalidate
>>>     before IBs if an IB is cached in L2 and the CPU has updated it.
>>>     It can only be cached in L2 if something other than CP has read
>>>     it or written to it without invalidation. CP reads don't cache
>>>     it but they can hit the cache if it's already cached.
>>>
>>>     For CE, we need to invalidate before the IB in the kernel,
>>>     because CE IBs can't do cache invalidations IIRC. This is the
>>>     number one reason for merging the already pushed commits.
>>>
>>>     Marek
>>>
>>>     On Sat., Apr. 25, 2020, 11:03 Christian König,
>>>     <ckoenig.leichtzumerken at gmail.com
>>>     <mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
>>>
>>>         Was that patch set actually merged upstream? My last status
>>>         is that we couldn't find a reason why we need to do this in
>>>         the kernel.
>>>
>>>         Christian.
>>>
>>>         Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>>>         This was missed.
>>>>
>>>>         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%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880865820&sdata=1eMdG%2Fr07okHFC%2F%2B3Oz4mg6dAvnd%2FULM6ucEoy7xXDc%3D&reserved=0>
>>>
>>>
>>>     _______________________________________________
>>>     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%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880875773&sdata=8IuVdWV7WS%2BZR60H8B9rWug64%2Bb7xnEUOucMzOlr1wY%3D&reserved=0>
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cdavid1.zhou%40amd.com%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880895689&sdata=6p%2BAuZXHiUrO8wElftOqsJzHF%2BVLe5TMDIF%2BbJNV6ac%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200428/af10f907/attachment-0001.htm>


More information about the amd-gfx mailing list