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, < [email protected]> 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 < > [email protected]> wrote: > >> [AMD Official Use Only - Internal Distribution Only] >> >> Do we have open source code UMD code which uses this? >> >> Alex >> ------------------------------ >> *From:* Christian König <[email protected]> >> *Sent:* Sunday, April 26, 2020 4:55 AM >> *To:* Marek Olšák <[email protected]>; Koenig, Christian < >> [email protected]> >> *Cc:* Deucher, Alexander <[email protected]>; amd-gfx mailing >> list <[email protected]> >> *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 >> <[email protected]> <[email protected]> >> >> 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, < >> [email protected]> 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 >> [email protected]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%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0> >> >> >> >> _______________________________________________ >> amd-gfx mailing >> [email protected]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%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0> >> >> >> > _______________________________________________ > amd-gfx mailing > [email protected]https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > >
_______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
