29f938a0ec
Commit64d6f56ad2("panfrost: Allocate syncobjs in panfrost_flush") aimed at optimizing the fencing logic but it looks it also broke the fence-based synchronization in subtle ways. Indeed, now that the fence only waits on a single syncobj, we're not guaranteed that all jobs queued in panfrost_flush_all_batches() will be done when the fence is signaled, because jobs at the top level (those stored in the batches hashmap) have not inter-dependencies. Commit9e397956b0("panfrost: signal syncobj if nothing is going to be flushed") made this even more apparent by signaling the fence right away if nothing was left to be drawn in the current context, thus ignoring any of the batches left to flushed in the ->batches map. If we want to keep relying the existing kernel APIs there's clearly no ideal solution here. We can either go back to the original fencing mechanism where each fence contained an array of syncobjs to be tested or serialize jobs that have no explicit dependencies so we know the last submitted job will also be the last one to return. The orginal approach has proven to add quite a significant overhead (caused by the amount of ioctls and the time spent in kernel space to gather dma fences attached to those syncobjs and test them). So let's go for the simple solution where we have a single syncobj bound to the context which we update to point to the last job out_sync every time we submit a top-level job. This approach implies reworking the way we create fences since we need to capture the syncobj state at the time the fence is created. Unfortunately, there's not SYNCOBJ_CLONE ioctl, which forces us to export/create/import a fence so we have a new object that's not subject to changes done to the context syncobj. If we want to further optimize the logic, we should probably explore some of those options: 1/ Adding array based SYNCOBJ ioctls (SYNCOBJ_{CREATE,DESTROY,CLONE}_ARRAY) so we can mitigate the cost of ioctls when we need to manipulate arrays of syncobjs 2/ Support synchronization jobs. That is, jobs that have a NULL job chain but an array of sync_in and a sync_out to allow creating synchronization points 3/ Add syncobj aggregators so we only have to wait on one syncobj from userspace. The syncobj aggregator would wait for all sub syncobjs to be signaled before signaling the top-level one. Fixes:64d6f56ad2("panfrost: Allocate syncobjs in panfrost_flush") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7831>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `Freenode's #dri-devel <irc://chat.freenode.net#dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.