diff --git a/docs/amber.rst b/docs/amber.rst index 28f48324c52..ba035e1d25b 100644 --- a/docs/amber.rst +++ b/docs/amber.rst @@ -42,5 +42,5 @@ Documentation On `docs.mesa3d.org `__, we currently only publish the documentation from our main branch. But you can view the documentation for the Amber branch `here -`_. +`__. diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst index 1b3804b4d57..31079d657d4 100644 --- a/docs/ci/LAVA.rst +++ b/docs/ci/LAVA.rst @@ -1,7 +1,7 @@ LAVA CI ======= -`LAVA `_ is a system for functional testing +`LAVA `__ 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 e8f11a67f1c..e42186c7478 100644 --- 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 -`_ +`__ 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 -`_). +`__). 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 6f07231e5e9..1dbe6f0f24c 100644 --- 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 -`_ help us +`__ 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 -`_ for +`__ 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 23a8284a86f..1435b2ae43e 100644 --- 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 `_ -- Install `Renderdoc `_ (only needed for some traces) -- Download and compile `Piglit `_ and install his `dependencies `_ -- Download traces you want to replay from `traces-db `_ +- Install `Apitrace `__ +- Install `Renderdoc `__ (only needed for some traces) +- Download and compile `Piglit `__ and install his `dependencies `__ +- Download traces you want to replay from `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 `_. +For more information, look into the `Apitrace documentation `__. For comparing checksums use: diff --git a/docs/ci/skqp.rst b/docs/ci/skqp.rst index 51f0979e1c3..0af11df9f5e 100644 --- a/docs/ci/skqp.rst +++ b/docs/ci/skqp.rst @@ -1,9 +1,9 @@ SkQP ==== -`SkQP `_ stands for SKIA Quality +`SkQP `__ stands for SKIA Quality Program conformance tests. Basically, it has sets of rendering tests and unit -tests to ensure that `SKIA `_ is meeting its design specifications on a specific +tests to ensure that `SKIA `__ 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 01200c11d7a..86045fa5d9b 100644 --- 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 -`_. +`__. External Structure ------------------ diff --git a/docs/drivers/radv.rst b/docs/drivers/radv.rst index 29a9046fdc6..5c37b95d594 100644 --- 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 -`_. +`__. ACO --- ACO is the shader-compiler used in RADV. You read its documentation -`here `_. +`here `__. diff --git a/docs/drivers/zink.rst b/docs/drivers/zink.rst index b5aebd14aff..2f4af305f0c 100644 --- 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 -`_. +`__. 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 53626d8684c..35b03997188 100644 --- 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 `_. -`Gallium 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 `_ with ``winetricks galliumnine``. -Aside from Wine, Gallium Nine works well with `Box86 `_. -Can be used via `Zink `_ even on the `Vulkan API `_. +Gallium Nine is commonly used in conjunction with `Wine `__. +`Gallium 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 `__ with ``winetricks galliumnine``. +Aside from Wine, Gallium Nine works well with `Box86 `__. +Can be used via `Zink `__ even on the `Vulkan API `__. 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 `_. +It's also possible to use D3D9 directly from the Linux environment. For tests, demos, and more details, you can see `this repository `__. Build ----- diff --git a/docs/macos.rst b/docs/macos.rst index e9d522eef37..018ab19af36 100644 --- 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 `_, which has a + Meson itself, are available in `homebrew `__, 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 bc91a41895e..3abaab5f02b 100644 --- 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 -`_, enumerates the +`__, 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