mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-13 05:30:16 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
2242bb703e
Other than nouveau, every single Gallium driver relies on u_pipe_screen_get_param_defaults to get the default values of CAPs. For the driver, this is much more concise. Unsupported new features -- or supported features that virtually all Gallium drivers support -- do not need to written out explicitly. Their absence (or presence) is implied as the default. If there's any doubt over whether the CAP is exposed, it's easy to check in u_pipe_screen_get_param_defaults. For the Gallium tree in general, this brings a number of benefits: * Unused CAPs are easy to delete, because there is only a single place (u_pipe_screen_get_param_defaults) where they are referenced and need to be deleted from. * New CAPs are easy to introduce, for the same reason. * It's straightforward to audit which drivers support (or don't support) a given CAP by grepping for the name (for example, when determining whether a CAP is unused and can be garbage collected, or a CAP is so widely supported that it can be made default.). You still need to check the source code in case it's conditionally exposed (common for layered drivers) but the search space is limited to drivers that reference the CAP by name. Unfortunately, all of these benefits rely on all Gallium drivers cooperating. The status quo is much less nice: * Unused CAPs need to be deleted both from common code, and also specially from nouveau. Why is nouveau special? * New CAPs need to be added both to common code, and also specially to nouveau. Again, why is nouveau special? * When grepping for CAPs, nouveau (only) needs to be ignored, since it's spurious. Unless sometimes it's not, in which case you need to open nouveau source code anyway to check. Compounding on the fun, you have to do the special nouveau step twice, once for nvc0 and once for nv50. Why might it be benefical to list CAPs explicitly instead of relying on the defaults? * Maybe easier auditing nouveau driver for CAP correctness? In practice this has not been an issue for any of the drivers I've worked on, especially because the defaults are quite reasonable. * Maybe forcing people adding CAPs to think about nouveau specially? This isn't fair to the tree in general, why should nouveau get this special treatment? Instead, CAPs are generally added to gate functionality that may not be supported on all drivers, and the default is disabling the new functionality until a developer for a given driver can wire it up. There's already no expectation that the person adding CAPs needs to also add the functionality to nouveau (if that's even possible) -- unless the CAP is being added for the particular nouveau's benefit of course -- so this isn't helpful. * Maybe forcing people removing CAPs to think about nouveau specially? Similar issues apply here, and it's not clear how this would even work. * Maybe keeping novueau developers aware of CAP churn? Again nouveau should not be special here and it isn't sustainable to do this for every driver. So, if this is something that nouveau developers want to do -- and they choose not to follow Gallium-tagged merge requests -- then the git log of src/gallium/include/pipe/p_defines.h or indeed src/gallium/auxiliary/util/u_screen.c may be consulted. So, without an excellent reason why nouveau should be treated specially, and with several reasons why it should not, let's bring nouveau in line with the rest of Gallium and rely on the defaults. I've left in CAPs with attached comments even when they are returning the default value to preserve information from before the commit. Otherwise, this commit aims to remove explicit cases that match the default value, as other drivers generally aim to do. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22245> |
||
|---|---|---|
| .github/workflows | ||
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| 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.