drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too

[Marek Olšák]

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/9125ef60/attachment-0001.htm>