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>

diff --git a/docs/amber.rst b/docs/amber.rst
index 28f4832..ba035e1 100644 (file)
--- a/docs/amber.rst
+++ b/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>`__.
 

diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst
index 1b3804b..31079d6 100644 (file)
--- a/docs/ci/LAVA.rst
+++ b/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

diff --git a/docs/ci/docker.rst b/docs/ci/docker.rst
index e8f11a6..e42186c 100644 (file)
--- a/docs/ci/docker.rst
+++ b/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

diff --git a/docs/ci/index.rst b/docs/ci/index.rst
index 6f07231..1dbe6f0 100644 (file)
--- a/docs/ci/index.rst
+++ b/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

diff --git a/docs/ci/local-traces.rst b/docs/ci/local-traces.rst
index 23a8284..1435b2a 100644 (file)
--- a/docs/ci/local-traces.rst
+++ b/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:
 

diff --git a/docs/ci/skqp.rst b/docs/ci/skqp.rst
index 51f0979..0af11df 100644 (file)
--- a/docs/ci/skqp.rst
+++ b/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

diff --git a/docs/drivers/freedreno/ir3-notes.rst b/docs/drivers/freedreno/ir3-notes.rst
index 01200c1..86045fa 100644 (file)
--- a/docs/drivers/freedreno/ir3-notes.rst
+++ b/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
 ------------------

diff --git a/docs/drivers/radv.rst b/docs/drivers/radv.rst
index 29a9046..5c37b95 100644 (file)
--- a/docs/drivers/radv.rst
+++ b/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>`__.

diff --git a/docs/drivers/zink.rst b/docs/drivers/zink.rst
index b5aebd1..2f4af30 100644 (file)
--- a/docs/drivers/zink.rst
+++ b/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

diff --git a/docs/gallium-nine.rst b/docs/gallium-nine.rst
index 53626d8..35b0399 100644 (file)
--- a/docs/gallium-nine.rst
+++ b/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
 -----

diff --git a/docs/macos.rst b/docs/macos.rst
index e9d522e..018ab19 100644 (file)
--- a/docs/macos.rst
+++ b/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

diff --git a/docs/vulkan/dispatch.rst b/docs/vulkan/dispatch.rst
index bc91a41..3abaab5 100644 (file)
--- a/docs/vulkan/dispatch.rst
+++ b/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