drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
Marek Olšák
maraeo at gmail.com
Tue Apr 28 05:16:23 UTC 2020
It's possible that what they really needed was the SDMA fix, so I don't
know if they need this flag anymore.
Marek
On Tue., Apr. 28, 2020, 01:12 Marek Olšák, <maraeo at gmail.com> wrote:
> No, Mesa won't use it. It's only necessary for the constant engine. My
> understanding from various discussions with the PAL team is that they need
> it, but I don't know if they even understand what the MEM_SYNC flag does.
>
> Marek
>
> On Mon., Apr. 27, 2020, 10:53 Christian König, <
> ckoenig.leichtzumerken at gmail.com> wrote:
>
>> 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> 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>
>>> *Sent:* Sunday, April 26, 2020 4:55 AM
>>> *To:* Marek Olšák <maraeo at gmail.com>; Koenig, Christian <
>>> Christian.Koenig at amd.com>
>>> *Cc:* Deucher, Alexander <Alexander.Deucher at amd.com>; amd-gfx mailing
>>> list <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> <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> 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 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%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>>
>>>
>>>
>> _______________________________________________
>> amd-gfx mailing listamd-gfx at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200428/bb6bd507/attachment.htm>
More information about the amd-gfx
mailing list