docs: use anonymous links when possible

Anonymous links has some benefits in that it reduces the chance of
warnings when similar identifiers are used. So let's use them instead
when we can.

Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19492>

docs/amber.rst

@@ -42,5 +42,5 @@ Documentation
 On `docs.mesa3d.org <https://docs.mesa3d.org/>`__, we currently only
 publish the documentation from our main branch. But you can view the
 documentation for the Amber branch `here
-<https://gitlab.freedesktop.org/mesa/mesa/-/tree/amber/docs>`_.
+<https://gitlab.freedesktop.org/mesa/mesa/-/tree/amber/docs>`__.
 

docs/ci/LAVA.rst

@@ -1,7 +1,7 @@
 LAVA CI
 =======
 
-`LAVA <https://lavasoftware.org/>`_ is a system for functional testing
+`LAVA <https://lavasoftware.org/>`__ is a system for functional testing
 of boards including deploying custom bootloaders and kernels.  This is
 particularly relevant to testing Mesa because we often need to change
 kernels for UAPI changes (and this lets us do full testing of a new

docs/ci/docker.rst

@@ -3,7 +3,7 @@ Docker CI
 
 For LLVMpipe and Softpipe CI, we run tests in a container containing
 VK-GL-CTS, on the shared GitLab runners provided by `freedesktop
-<http://freedesktop.org>`_
+<http://freedesktop.org>`__
 
 Software architecture
 ---------------------
@@ -53,7 +53,7 @@ step across multiple test runs.  Since the images are large and change
 approximately weekly, the DUTs also need to be running some script to
 prune stale Docker images periodically in order to not run out of disk
 space as we rev those containers (perhaps `this script
-<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_).
+<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`__).
 
 Note that Docker doesn't allow containers to be stored on NFS, and
 doesn't allow multiple Docker daemons to interact with the same

docs/ci/index.rst

@@ -191,7 +191,7 @@ Docker caching
 The CI system uses Docker images extensively to cache
 infrequently-updated build content like the CTS.  The `freedesktop.org
 CI templates
-<https://gitlab.freedesktop.org/freedesktop/ci-templates/>`_ help us
+<https://gitlab.freedesktop.org/freedesktop/ci-templates/>`__ help us
 manage the building of the images to reduce how frequently rebuilds
 happen, and trim down the images (stripping out manpages, cleaning the
 apt cache, and other such common pitfalls of building Docker images).
@@ -211,7 +211,7 @@ When developing a given change to your Docker image, you would have to
 bump the tag on each ``git commit --amend`` to your development
 branch, which can get tedious.  Instead, you can navigate to the
 `container registry
-<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`_ for
+<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`__ for
 your repository and delete the tag to force a rebuild.  When your code
 is eventually merged to main, a full image rebuild will occur again
 (forks inherit images from the main repo, but MRs don't propagate

docs/ci/local-traces.rst

@@ -3,10 +3,10 @@ Running traces on a local machine
 
 Prerequisites
 -------------
-- Install `Apitrace <https://apitrace.github.io/>`_
-- Install `Renderdoc <https://renderdoc.org/>`_ (only needed for some traces)
-- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`_ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`_
-- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`_
+- Install `Apitrace <https://apitrace.github.io/>`__
+- Install `Renderdoc <https://renderdoc.org/>`__ (only needed for some traces)
+- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`__ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`__
+- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`__
 
 Running single trace
 --------------------
@@ -16,7 +16,7 @@ A simple run to see the output of the trace can be done with
 
     apitrace replay -w name_of_trace.trace
 
-For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`_.
+For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`__.
 
 For comparing checksums use:
 

docs/ci/skqp.rst

@@ -1,9 +1,9 @@
 SkQP
 ====
 
-`SkQP <https://skia.org/docs/dev/testing/skqp/>`_ stands for SKIA Quality
+`SkQP <https://skia.org/docs/dev/testing/skqp/>`__ stands for SKIA Quality
 Program conformance tests.  Basically, it has sets of rendering tests and unit
-tests to ensure that `SKIA <https://skia.org/>`_ is meeting its design specifications on a specific
+tests to ensure that `SKIA <https://skia.org/>`__ is meeting its design specifications on a specific
 device.
 
 The rendering tests have support for GL, GLES and Vulkan backends and test some

docs/drivers/freedreno/ir3-notes.rst

@@ -15,7 +15,7 @@ Here, the second instruction needs the output of the first group of scalar instr
 So the current compiler instead, in the frontend, generates a directed-acyclic-graph of instructions and basic blocks, which go through various additional passes to eventually schedule and do register assignment.
 
 For additional documentation about the hardware, see wiki: `a3xx ISA
-<https://github.com/freedreno/freedreno/wiki/A3xx-shader-instruction-set-architecture>`_.
+<https://github.com/freedreno/freedreno/wiki/A3xx-shader-instruction-set-architecture>`__.
 
 External Structure
 ------------------

docs/drivers/radv.rst

@@ -14,10 +14,10 @@ Hardware Documentation
 
 You can find a list of documentation for the various generations of
 AMD hardware on the `X.Org wiki
-<https://www.x.org/wiki/RadeonFeature/#documentation>`_.
+<https://www.x.org/wiki/RadeonFeature/#documentation>`__.
 
 ACO
 ---
 
 ACO is the shader-compiler used in RADV. You read its documentation
-`here <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/compiler/README.md>`_.
+`here <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/compiler/README.md>`__.

docs/drivers/zink.rst

@@ -290,7 +290,7 @@ Vulkan Validation Layers
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Another useful tool for debugging is the `Vulkan Validation Layers
-<https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/README.md>`_.
+<https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/README.md>`__.
 
 The validation layers effectively insert extra checking between Zink and the
 Vulkan driver, pointing out incorrect usage of the Vulkan API. The layers can

docs/gallium-nine.rst

@@ -6,14 +6,14 @@ The Gallium frontend, which implements Direct3D 9.
 Nine implements the full IDirect3DDevice9 COM interface and a custom COM interface called ID3DAdapter9, which is used to implement the final IDirect3D9Ex COM interface.
 ID3DAdapter9 is completely agnostic regarding the window system code, meaning this can be provided by wine, Xlib, Wayland, etc.
 
-Gallium Nine is commonly used in conjunction with `Wine <https://www.winehq.org/>`_.
-`Gallium Nine Standalone <https://github.com/iXit/wine-nine-standalone>`_ is the standalone version of the Wine parts of Gallium Nine which makes it possible to use it with any stock Wine version. It's simple to install through `Winetricks <https://github.com/Winetricks/winetricks>`_ with ``winetricks galliumnine``.
-Aside from Wine, Gallium Nine works well with `Box86 <https://ptitseb.github.io/box86/>`_.
-Can be used via `Zink <https://www.supergoodcode.com/to-the-nines/>`_ even on the `Vulkan API <https://en.wikipedia.org/wiki/Vulkan>`_.
+Gallium Nine is commonly used in conjunction with `Wine <https://www.winehq.org/>`__.
+`Gallium Nine Standalone <https://github.com/iXit/wine-nine-standalone>`__ is the standalone version of the Wine parts of Gallium Nine which makes it possible to use it with any stock Wine version. It's simple to install through `Winetricks <https://github.com/Winetricks/winetricks>`__ with ``winetricks galliumnine``.
+Aside from Wine, Gallium Nine works well with `Box86 <https://ptitseb.github.io/box86/>`__.
+Can be used via `Zink <https://www.supergoodcode.com/to-the-nines/>`__ even on the `Vulkan API <https://en.wikipedia.org/wiki/Vulkan>`__.
 
 In the majority of cases this implementation has better performance than Wine doing the translation from D3D9 to OpenGL itself.
 
-It's also possible to use D3D9 directly from the Linux environment. For tests, demos, and more details, you can see `this repository <https://github.com/iXit/nine-tests>`_.
+It's also possible to use D3D9 directly from the Linux environment. For tests, demos, and more details, you can see `this repository <https://github.com/iXit/nine-tests>`__.
 
 Build
 -----

docs/macos.rst

@@ -9,7 +9,7 @@ Mesa builds on macOS without modifications. However, there are some details to
 be aware of.
 
 -  Mesa has a number of build-time dependencies. Most dependencies, including
-   Meson itself, are available in `homebrew <https://brew.sh>`_, which has a
+   Meson itself, are available in `homebrew <https://brew.sh>`__, which has a
    Mesa package for reference. The exception seems to be Mako, a Python module
    used for templating, which you can install as ``pip3 install mako``.
 -  macOS is picky about its build-time environment. Type ``brew sh`` before

docs/vulkan/dispatch.rst

@@ -41,7 +41,7 @@ to iterate over the table.
 
 These tables are are generated automatically using a bit of python code that
 parses the vk.xml from the `Vulkan-Docs repo
-<https://github.com/KhronosGroup/Vulkan-docs/>`_, enumerates the
+<https://github.com/KhronosGroup/Vulkan-docs/>`__, enumerates the
 extensions, sorts them by instance vs. device and generates the table.
 Generating it from XML means that we never have to manually maintain any of
 these data structures; they get automatically updated when someone imports