drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
Marek Olšák
maraeo at gmail.com
Mon Apr 27 13:54:43 UTC 2020
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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200427/6bbe98eb/attachment.htm>
More information about the amd-gfx
mailing list