mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-24 15:20:10 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
fa97061a82
To facilitate cross-process timeline semaphores we have to deal with the fact that the syncobj signal operation might be submitted a small finite time after the wait operation. For that we start using DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT during the wait operation so we properly wait instead of returning an error. Furthermore, to make this effective for syncobjs that get reused we actually have to reset them after the wait. Otherwise the wait before submit would get the previous fence instead of waiting for the new thing to submit. The obvious choice, resetting the syncobj after the CS submission has 2 issues though: 1) If the same semaphore is used for wait and signal we can't reset it. This is solvable by only resetting the semaphores that are not in the signal list. 2) The submitted work might be complete before we get to resetting the syncobj. If there is a cycle of submissions that signals it again and finishes before we get to the reset we are screwed. Solution: Copy the fence into a new syncobj and reset the old syncobj before submission. Yes I know it is more syscalls :( At least I reduced the alloc/free overhead by keeping a cache of temporary syncobjs. This also introduces a syncobj_reset_count as we don't want to reset syncobjs that are part of an emulated timeline semaphore. (yes, if the kernel supports timeline syncobjs we should use those instead, but those still need to be implemented and if we depend on them in this patch ordering dependencies get hard ...) Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5600> |
||
|---|---|---|
| .appveyor | ||
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| bin | ||
| build-support | ||
| docs | ||
| doxygen | ||
| include | ||
| scons | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| Android.common.mk | ||
| Android.mk | ||
| appveyor.yml | ||
| CleanSpec.mk | ||
| common.py | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| REVIEWERS | ||
| SConstruct | ||
| VERSION | ||
`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.