mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-18 00:48:07 +02:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
24ebcbbaa7
Until now, we have always consumed barriers with the next GPU job recorded into the command buffer after the barrier even if the job was not the target of the barrier itself. This works based on the idea that when we consume a barrier in a job we serialize it against all queues, so effectively we are ensuring that whatever came before it has completed, so if the barrier was intended for an even later job, it would have served its purpose anyway. It should be noted that CL jobs are special because they are actually split in two different queues: the binning queue and the render queue, with a dependency between them to ensure render runs after binning. With our current implementation, if we have 3 jobs (A, B, C) and we have a barrier after job A which is intended to block job C on A's completion, with our implementation we would instead block B on A's completion. If C is a CL job, and the barrier was targetting the binning stage then we can have the following scenarios: 1. If B) is a CL job, it will consume the barrier at its binning stage, so we know that B's binning will not start until A has completed. Then C's binning will not start until B's binning has completed, and thus, will not start until A has completed, as intended. 2. If B) is not a CL job, it will consume the barrier and will not start until A has completed, however, C's binning job will be submitted to the binning queue without any sync requirements and since B did not put any jobs in the binning queue it will start as soon as A's binning has completed, but not A's render, which would be incorrect. Further, since |
||
|---|---|---|
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| CODEOWNERS | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| 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 `OFTC's #dri-devel <irc://irc.oftc.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.