docs: use ext-role for GL / VK extensions

This makes sure that we generate proper links to all of these
extensions.

Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19594>

20 files changed, 171 insertions, 187 deletions

diff --git a/docs/drivers/anv.rst b/docs/drivers/anv.rst
index be774eee46b..05a5534a26b 100644
--- a/docs/drivers/anv.rst
+++ b/docs/drivers/anv.rst
@@ -14,7 +14,7 @@ specific to ANV:
 :envvar:`ANV_DISABLE_SECONDARY_CMD_BUFFER_CALLS`
    If defined to ``1`` or ``true``, this will prevent usage of self
    modifying command buffers to implement ``vkCmdExecuteCommands``. As
-   a result of this, it will also disable ``VK_KHR_performance_query``.
+   a result of this, it will also disable :ext:`VK_KHR_performance_query`.
 :envvar:`ANV_ALWAYS_BINDLESS`
    If defined to ``1`` or ``true``, this forces all descriptor sets to
    use the internal `Bindless model`_.
@@ -28,7 +28,7 @@ specific to ANV:
    Haswell, Cherryview).
 :envvar:`ANV_PRIMITIVE_REPLICATION_MAX_VIEWS`
    Specifies up to how many view shaders can be lowered to handle
-   VK_KHR_multiview. Beyond this number, multiview is implemented
+   :ext:`VK_KHR_multiview`. Beyond this number, multiview is implemented
    using instanced rendering. If unspecified, the value default to
    ``2``.
 
@@ -38,7 +38,7 @@ Experimental features
 
 :envvar:`ANV_EXPERIMENTAL_NV_MESH_SHADER`
    If defined to ``1`` or ``true``, this advertise support for
-   VK_NV_mesh_shader extension for platforms that have hardware
+   :ext:`VK_NV_mesh_shader` extension for platforms that have hardware
    support for it.
 
 
diff --git a/docs/drivers/lima.rst b/docs/drivers/lima.rst
index 94fbae75bd8..57c968258bd 100644
--- a/docs/drivers/lima.rst
+++ b/docs/drivers/lima.rst
@@ -131,9 +131,9 @@ Here are some known caveats in OpenGL support:
     that may affect the quality of the texture lookup.
 
 - Lima supports FP16 textures in OpenGL ES (through
-  ``GL_OES_texture_half_float``), but not in OpenGL.
-  This is because it would require ``ARB_texture_float`` which would also
-  require 32-bit float textures, that the Mali-4xx does not support.
+  :ext:`GL_OES_texture_half_float<GL_OES_texture_float>`), but not in OpenGL.
+  This is because it would require :ext:`GL_ARB_texture_float` which would
+  also require 32-bit float textures, that the Mali-4xx does not support.
 - Rendering to FP16 is possible, but the result is clamped to the
   [0.0,1.0] range.
 
diff --git a/docs/drivers/svga3d.rst b/docs/drivers/svga3d.rst
index 04fc564e62a..f18d9bd30ce 100644
--- a/docs/drivers/svga3d.rst
+++ b/docs/drivers/svga3d.rst
@@ -23,12 +23,12 @@ With the Fall 2018 Workstation 15 / Fusion 11 releases, additional
 features are supported in the driver:
 
 -  Multisample antialiasing (2x, 4x)
--  GL_ARB/AMD_draw_buffers_blend
--  GL_ARB_sample_shading
--  GL_ARB_texture_cube_map_array
--  GL_ARB_texture_gather
--  GL_ARB_texture_query_lod
--  GL_EXT/OES_draw_buffers_indexed
+-  :ext:`GL_ARB_draw_buffers_blend` / :ext:`GL_AMD_draw_buffers_blend`
+-  :ext:`GL_ARB_sample_shading`
+-  :ext:`GL_ARB_texture_cube_map_array`
+-  :ext:`GL_ARB_texture_gather`
+-  :ext:`GL_ARB_texture_query_lod`
+-  :ext:`GL_EXT_draw_buffers_indexed` / :ext:`GL_OES_draw_buffers_indexed`
 
 This requires version 2.15.0 or later of the vmwgfx kernel module and
 the VM must be configured for hardware version 16 or later.
diff --git a/docs/drivers/venus.rst b/docs/drivers/venus.rst
index dd337a05db6..0a057b0a31e 100644
--- a/docs/drivers/venus.rst
+++ b/docs/drivers/venus.rst
@@ -16,9 +16,9 @@ Requirements
 The Venus renderer requires
 
 - Vulkan 1.1
-- ``VK_EXT_external_memory_dma_buf``
-- ``VK_EXT_image_drm_format_modifier``
-- ``VK_EXT_queue_family_foreign``
+- :ext:`VK_EXT_external_memory_dma_buf`
+- :ext:`VK_EXT_image_drm_format_modifier`
+- :ext:`VK_EXT_queue_family_foreign`
 
 from the host driver.  However, it violates the spec in some places currently
 and also relies on implementation-defined behaviors in others.  It is not
@@ -161,8 +161,8 @@ driver supports the formats, especially multi-planar ones, and the DRM format
 modifiers of the GBM BOs.
 
 In the future, if virglrenderer's ``virgl_renderer_export_fence`` is
-supported, the Venus renderer will require ``VK_KHR_external_fence_fd`` with
-``VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT`` from the host driver.
+supported, the Venus renderer will require :ext:`VK_KHR_external_fence_fd`
+with ``VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT`` from the host driver.
 
 VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
 -----------------------------------
diff --git a/docs/drivers/zink.rst b/docs/drivers/zink.rst
index 2f4af305f0c..c3a3c1e60ac 100644
--- a/docs/drivers/zink.rst
+++ b/docs/drivers/zink.rst
@@ -44,13 +44,13 @@ Here's a list of those requirements:
 
 * Device extensions:
 
-  * `VK_KHR_maintenance1`_
-  * `VK_KHR_create_renderpass2`_
-  * `VK_KHR_imageless_framebuffer`_
-  * `VK_KHR_timeline_semaphore`_
-  * `VK_EXT_custom_border_color`_ with ``customBorderColorWithoutFormat``
-  * `VK_EXT_provoking_vertex`_
-  * `VK_EXT_line_rasterization`_, with the following ``VkPhysicalDeviceLineRasterizationFeaturesEXT``:
+  * :ext:`VK_KHR_maintenance1`
+  * :ext:`VK_KHR_create_renderpass2`
+  * :ext:`VK_KHR_imageless_framebuffer`
+  * :ext:`VK_KHR_timeline_semaphore`
+  * :ext:`VK_EXT_custom_border_color` with ``customBorderColorWithoutFormat``
+  * :ext:`VK_EXT_provoking_vertex`
+  * :ext:`VK_EXT_line_rasterization`, with the following ``VkPhysicalDeviceLineRasterizationFeaturesEXT``:
 
     * ``rectangularLines``
     * ``bresenhamLines``
@@ -59,14 +59,14 @@ Here's a list of those requirements:
     * ``stippledBresenhamLines``
     * ``stippledSmoothLines``
 
-  * `VK_KHR_swapchain_mutable_format`_
-  * `VK_EXT_border_color_swizzle`_
-  * `VK_KHR_descriptor_update_template`_
+  * :ext:`VK_KHR_swapchain_mutable_format`
+  * :ext:`VK_EXT_border_color_swizzle`
+  * :ext:`VK_KHR_descriptor_update_template`
 
-In addition to this, `VK_KHR_external_memory`_ is required to support the
+In addition to this, :ext:`VK_KHR_external_memory` is required to support the
 DRI code-path.
 
-We also require either the `VK_EXT_scalar_block_layout`_ extension or
+We also require either the :ext:`VK_EXT_scalar_block_layout` extension or
 Vulkan 1.2, with the ``scalarBlockLayout`` feature.
 
 OpenGL 3.0
@@ -82,8 +82,8 @@ supported:
 
 * Device extensions:
 
-  * `VK_EXT_transform_feedback`_
-  * `VK_EXT_conditional_rendering`_
+  * :ext:`VK_EXT_transform_feedback`
+  * :ext:`VK_EXT_conditional_rendering`
 
 OpenGL 3.1
 ^^^^^^^^^^
@@ -107,7 +107,7 @@ supported, although some of these might not actually get verified:
 
 * Device extensions:
 
-  * `VK_EXT_depth_clip_enable`_
+  * :ext:`VK_EXT_depth_clip_enable`
 
 OpenGL 3.3
 ^^^^^^^^^^
@@ -121,7 +121,7 @@ supported, although some of these might not actually get verified:
 
 * Device extensions:
 
-  * `VK_EXT_vertex_attribute_divisor`_
+  * :ext:`VK_EXT_vertex_attribute_divisor`
 
 OpenGL 4.0
 ^^^^^^^^^^
@@ -137,7 +137,7 @@ supported:
 
 * Device extensions:
 
-  * `VK_KHR_maintenance2`_
+  * :ext:`VK_KHR_maintenance2`
 
 * Formats requiring ``VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT``:
 
@@ -167,7 +167,7 @@ For OpenGL 4.2 support, the following additional requirements must be
 supported:
 
 * Device extensions:
-    * `VK_EXT_image_2d_view_of_3d`_
+    * :ext:`VK_EXT_image_2d_view_of_3d`
 
 * ``VkPhysicalDeviceLimits``:
 
@@ -187,7 +187,7 @@ supported:
 
   * Device extensions:
 
-    * `VK_KHR_shader_draw_parameters`_
+    * :ext:`VK_KHR_shader_draw_parameters`
 
 OpenGL 4.3
 ^^^^^^^^^^
@@ -221,7 +221,7 @@ supported:
 
 * Device extensions:
 
-  * `VK_KHR_sampler_mirror_clamp_to_edge`_
+  * :ext:`VK_KHR_sampler_mirror_clamp_to_edge`
 
 OpenGL 4.5
 ^^^^^^^^^^
@@ -245,7 +245,7 @@ are required to be supported
 
 * Device extensions:
 
-  * `VK_KHR_draw_indirect_count`_
+  * :ext:`VK_KHR_draw_indirect_count`
 
 Performance
 -----------
@@ -308,24 +308,3 @@ questions, don't hesitate to visit `#zink on OFTC
 
 
 .. _downloaded from GPUinfo.org: https://www.saschawillems.de/blog/2022/03/12/vulkan-profiles-support-for-the-vulkan-hardware-capability-viewer-and-database/>
-.. _VK_KHR_maintenance1: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_maintenance1.html
-.. _VK_KHR_create_renderpass2: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_create_renderpass2.html
-.. _VK_KHR_imageless_framebuffer: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_imageless_framebuffer.html
-.. _VK_KHR_timeline_semaphore: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_timeline_semaphore.html
-.. _VK_KHR_external_memory: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_external_memory.html
-.. _VK_EXT_scalar_block_layout: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_scalar_block_layout.html
-.. _VK_EXT_transform_feedback: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_transform_feedback.html
-.. _VK_EXT_conditional_rendering: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_conditional_rendering.html
-.. _VK_EXT_vertex_attribute_divisor: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_vertex_attribute_divisor.html
-.. _VK_EXT_image_2d_view_of_3d: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_EXT_image_2d_view_of_3d.html
-.. _VK_KHR_maintenance2: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_maintenance2.html
-.. _VK_KHR_shader_draw_parameters: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_shader_draw_parameters.html
-.. _VK_KHR_draw_indirect_count: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_draw_indirect_count.html
-.. _VK_KHR_sampler_mirror_clamp_to_edge: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_sampler_mirror_clamp_to_edge.html
-.. _VK_EXT_custom_border_color: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_custom_border_color.html
-.. _VK_EXT_provoking_vertex: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_provoking_vertex.html
-.. _VK_EXT_line_rasterization: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_line_rasterization.html
-.. _VK_KHR_swapchain_mutable_format: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_swapchain_mutable_format.html
-.. _VK_EXT_border_color_swizzle: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_border_color_swizzle.html
-.. _VK_EXT_depth_clip_enable: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_EXT_depth_clip_enable.html
-.. _VK_KHR_descriptor_update_template: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_KHR_descriptor_update_template.html
diff --git a/docs/envvars.rst b/docs/envvars.rst
index caac6b610bd..8c65714b387 100644
--- a/docs/envvars.rst
+++ b/docs/envvars.rst
@@ -40,8 +40,8 @@ Core Mesa environment variables
 :envvar:`MESA_NO_SSE`
    if set, disables Intel SSE optimizations
 :envvar:`MESA_NO_ERROR`
-   if set to 1, error checking is disabled as per ``KHR_no_error``. This
-   will result in undefined behavior for invalid use of the API, but
+   if set to 1, error checking is disabled as per :ext:`GL_KHR_no_error`.
+   This will result in undefined behavior for invalid use of the API, but
    can reduce CPU use for apps that are known to be error free.
 :envvar:`MESA_DEBUG`
    if set, error messages are printed to stderr. For example, if the
@@ -89,11 +89,11 @@ Core Mesa environment variables
    -  ``FC`` is an optional suffix that indicates a forward compatible
       context. This is only valid for versions >= 3.0.
    -  ``COMPAT`` is an optional suffix that indicates a compatibility
-      context or ``GL_ARB_compatibility`` support. This is only valid
+      context or :ext:`GL_ARB_compatibility` support. This is only valid
       for versions >= 3.1.
    -  GL versions <= 3.0 are set to a compatibility (non-Core) profile
    -  GL versions = 3.1, depending on the driver, it may or may not have
-      the ``ARB_compatibility`` extension enabled.
+      the :ext:`GL_ARB_compatibility` extension enabled.
    -  GL versions >= 3.2 are set to a Core profile
    -  Examples:
 
@@ -104,13 +104,13 @@ Core Mesa environment variables
       ``3.0FC``
          select a Core+Forward Compatible profile with GL version 3.0.
       ``3.1``
-         select GL version 3.1 with ``GL_ARB_compatibility`` enabled per
-         the driver default.
+         select GL version 3.1 with :ext:`GL_ARB_compatibility` enabled
+         per the driver default.
       ``3.1FC``
          select GL version 3.1 with forward compatibility and
-         ``GL_ARB_compatibility`` disabled.
+         :ext:`GL_ARB_compatibility` disabled.
       ``3.1COMPAT``
-         select GL version 3.1 with ``GL_ARB_compatibility`` enabled.
+         select GL version 3.1 with :ext:`GL_ARB_compatibility` enabled.
       ``X.Y``
          override GL version to X.Y without changing the profile.
       ``X.YFC``
@@ -332,7 +332,7 @@ Intel driver environment variables
    ``perf``
       emit messages about performance issues
    ``perfmon``
-      emit messages about ``AMD_performance_monitor``
+      emit messages about :ext:`GL_AMD_performance_monitor`
    ``reemit``
       mark all state dirty on each draw call
    ``rt``
diff --git a/docs/faq.rst b/docs/faq.rst
index e0227a0d006..f1c1158d62f 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -292,8 +292,8 @@ being said, many people have managed to figure out the process.
 Joining the appropriate mailing lists and asking questions (and
 searching the archives) is a good way to get information.
 
-4.3 Why isn't ``GL_EXT_texture_compression_s3tc`` implemented in Mesa?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+4.3 Why isn't :ext:`GL_EXT_texture_compression_s3tc` implemented in Mesa?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Oh but it is! Prior to 2nd October 2017, the Mesa project did not
 include S3TC support due to intellectual property (IP) and/or patent
diff --git a/docs/gallium/buffermapping.rst b/docs/gallium/buffermapping.rst
index bd8fc6d4a5c..0681e8fc1fa 100644
--- a/docs/gallium/buffermapping.rst
+++ b/docs/gallium/buffermapping.rst
@@ -182,7 +182,7 @@ Euro Truck Simulator
   893943 glDrawArrays(mode = GL_TRIANGLES, first = 0, count = 6)
 
 At the start of this frame, buffer 14 and 15 haven't been used in the previous 2
-frames, and the ``GL_ARB_sync`` fence has ensured that the GPU has at least started
+frames, and the :ext:`GL_ARB_sync` fence has ensured that the GPU has at least started
 frame n-1 as the CPU starts the current frame. The first map is ``offset = 0,
 INVALIDATE_BUFFER | UNSYNCHRONIZED``, which suggests that the driver should
 reallocate storage for the mapping even in the ``UNSYNCHRONIZED`` case, except
@@ -237,7 +237,7 @@ Plague Inc
   1640863 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 6, type = GL_UNSIGNED_SHORT, indices = 0x58, basevertex = 4)
 
 At the start of this frame, the VBOs haven't been used in about 6 frames, and
-the ``GL_ARB_sync`` fence has ensured that the GPU has started frame n-1.
+the :ext:`GL_ARB_sync` fence has ensured that the GPU has started frame n-1.
 
 Note the use of ``glFlushMappedBufferRange()`` on a small fraction of the size
 of the VBO -- it is important that a blitting driver make use of the flush
@@ -299,7 +299,7 @@ Tabletop Simulator
   1289068 glDrawArrays(mode = GL_TRIANGLE_STRIP, first = 8, count = 4)
   1289553 glXSwapBuffers(dpy = 0x3e10810, drawable = 23068692)
 
-In this app, buffer 480 gets used like this every other frame.  The ``GL_ARB_sync``
+In this app, buffer 480 gets used like this every other frame.  The :ext:`GL_ARB_sync`
 fence ensures that frame n-1 has started on the GPU before CPU work starts on
 the current frame, so the unsynchronized access to the buffers is safe.
 
@@ -337,7 +337,7 @@ Hollow Knight
   1873097 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 36, type = GL_UNSIGNED_SHORT, indices = 0x2d0, basevertex = 240)
 
 In this app, buffer 29/30 get used like this starting from offset 0 every other
-frame.  The ``GL_ARB_sync`` fence is used to make sure that the GPU has reached the
+frame.  The :ext:`GL_ARB_sync` fence is used to make sure that the GPU has reached the
 start of the previous frame before we go unsynchronized writing over the n-2
 frame's buffer.
 
@@ -363,7 +363,7 @@ Borderlands 2
   3563064 glBindBufferARB(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 875)
   3563065 glDrawElementsInstancedARB(mode = GL_TRIANGLES, count = 72, type = GL_UNSIGNED_SHORT, indices = NULL, instancecount = 28)
 
-The ``GL_ARB_sync`` fence ensures that the GPU has started frame n-1 before the CPU
+The :ext:`GL_ARB_sync` fence ensures that the GPU has started frame n-1 before the CPU
 starts on the current frame.
 
 This sequence of buffer uploads appears in each frame with the same buffer
diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst
index 612bdacdd3b..cb7ac1f07a9 100644
--- a/docs/gallium/context.rst
+++ b/docs/gallium/context.rst
@@ -102,7 +102,7 @@ objects. They all follow simple, one-method binding calls, e.g.
   PIPE_MAX_VIEWPORTS.
 * ``set_viewport_states``
 * ``set_window_rectangles`` sets the window rectangles to be used for
-  rendering, as defined by GL_EXT_window_rectangles. There are two
+  rendering, as defined by :ext:`GL_EXT_window_rectangles`. There are two
   modes - include and exclude, which define whether the supplied
   rectangles are to be used for including fragments or excluding
   them. All of the rectangles are ORed together, so in exclude mode,
@@ -122,7 +122,7 @@ objects. They all follow simple, one-method binding calls, e.g.
   for tessellation.
 
 * ``set_debug_callback`` sets the callback to be used for reporting
-  various debug messages, eventually reported via KHR_debug and
+  various debug messages, eventually reported via :ext:`GL_KHR_debug` and
   similar mechanisms.
 
 Samplers
diff --git a/docs/gallium/cso/rasterizer.rst b/docs/gallium/cso/rasterizer.rst
index 38ee9e4868f..430653ccc34 100644
--- a/docs/gallium/cso/rasterizer.rst
+++ b/docs/gallium/cso/rasterizer.rst
@@ -15,7 +15,8 @@ clamp_vertex_color
    the execution of the vertex shader, before being passed to the geometry
    shader or fragment shader.
 
-   OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or GL_ARB_color_buffer_float
+   OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or
+   :ext:`GL_ARB_color_buffer_float`
 
    D3D11: seems always disabled
 
@@ -28,7 +29,8 @@ clamp_fragment_color
    Controls whether TGSI_SEMANTIC_COLOR outputs of the fragment shader
    are clamped to [0, 1].
 
-   OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or ARB_color_buffer_float
+   OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or
+   :ext:`GL_ARB_color_buffer_float`
 
    D3D11: seems always disabled
 
diff --git a/docs/gallium/resources.rst b/docs/gallium/resources.rst
index 727899c4956..87fca544b63 100644
--- a/docs/gallium/resources.rst
+++ b/docs/gallium/resources.rst
@@ -69,11 +69,11 @@ TODO there's no CAP bit currently for this, there's also unspecified size etc. l
 TODO: is there any chance of supporting GL pixel buffer object acceleration with this?
 
 
-OpenGL: vertex buffers in GL 1.5 or GL_ARB_vertex_buffer_object
+OpenGL: vertex buffers in GL 1.5 or :ext:`GL_ARB_vertex_buffer_object`
 
-- Binding to stream out requires GL 3.0 or GL_NV_transform_feedback
-- Binding as constant buffers requires GL 3.1 or GL_ARB_uniform_buffer_object
-- Binding to a sampling stage requires GL 3.1 or GL_ARB_texture_buffer_object
+- Binding to stream out requires GL 3.0 or :ext:`GL_NV_transform_feedback`
+- Binding as constant buffers requires GL 3.1 or :ext:`GL_ARB_uniform_buffer_object`
+- Binding to a sampling stage requires GL 3.1 or :ext:`GL_ARB_texture_buffer_object`
 
 D3D11: buffer resources
 - Binding to a render target requires D3D_FEATURE_LEVEL_10_0
@@ -93,7 +93,7 @@ PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY
 
 OpenGL: GL_TEXTURE_1D in GL 1.0
 
-- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
+- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
 
 D3D11: 1D textures in D3D_FEATURE_LEVEL_10_0
 
@@ -107,7 +107,8 @@ PIPE_TEXTURE_RECT
 - Must use unnormalized coordinates
 - Must use a clamp wrap mode
 
-OpenGL: GL_TEXTURE_RECTANGLE in GL 3.1 or GL_ARB_texture_rectangle or GL_NV_texture_rectangle
+OpenGL: GL_TEXTURE_RECTANGLE in GL 3.1 or :ext:`GL_ARB_texture_rectangle` or
+:ext:`GL_NV_texture_rectangle`
 
 OpenCL: can create OpenCL images based on this, that can then be sampled arbitrarily
 
@@ -128,7 +129,7 @@ PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY
 
 OpenGL: GL_TEXTURE_2D in GL 1.0
 
-- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
+- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
 
 OpenCL: can create OpenCL images based on this, that can then be sampled arbitrarily
 
@@ -147,9 +148,9 @@ Mipmap dimensions are reduced in all 3 coordinates.
 - array_size must be 1
 - Must use normalized coordinates
 
-OpenGL: GL_TEXTURE_3D in GL 1.2 or GL_EXT_texture3D
+OpenGL: GL_TEXTURE_3D in GL 1.2 or :ext:`GL_EXT_texture3D`
 
-- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
+- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
 
 D3D11: 3D textures
 
@@ -173,11 +174,11 @@ resulting in filtering taking samples from multiple surfaces near to the edge.
       width and height must be powers of two
 - Must use normalized coordinates
 
-OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or EXT_texture_cube_map
+OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or :ext:`GL_EXT_texture_cube_map`
 
-- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
-- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_AMD_seamless_cubemap_per_texture
-- Cube map arrays require GL 4.0 or GL_ARB_texture_cube_map_array
+- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
+- Seamless cube maps require GL 3.2 or :ext:`GL_ARB_seamless_cube_map` or :ext:`GL_AMD_seamless_cubemap_per_texture`
+- Cube map arrays require GL 4.0 or :ext:`GL_ARB_texture_cube_map_array`
 
 D3D11: 2D array textures with the D3D11_RESOURCE_MISC_TEXTURECUBE flag
 
@@ -191,7 +192,7 @@ Surfaces are views of a resource that can be bound as a framebuffer to serve as
 
 TODO: write much more on surfaces
 
-OpenGL: FBOs are collections of surfaces in GL 3.0 or GL_ARB_framebuffer_object
+OpenGL: FBOs are collections of surfaces in GL 3.0 or :ext:`GL_ARB_framebuffer_object`
 
 D3D11: render target views and depth/stencil views
 
diff --git a/docs/gallium/screen.rst b/docs/gallium/screen.rst
index 882cb6d65d1..1340ea5fb0b 100644
--- a/docs/gallium/screen.rst
+++ b/docs/gallium/screen.rst
@@ -119,8 +119,9 @@ The integer capabilities:
   is allowed to return ``0`` in which case ``PIPE_CAP_GLSL_FEATURE_LEVEL`` is
   used.
   Note that simply returning the same value as the GLSL feature level cap is
-  incorrect.  For example, GLSL version 3.30 does not require ``ARB_gpu_shader5``,
-  but ESSL version 3.20 es does require ``EXT_gpu_shader5``
+  incorrect.  For example, GLSL version 3.30 does not require
+  :ext:`GL_EXT_gpu_shader5`, but ESSL version 3.20 es does require
+  :ext:`GL_EXT_gpu_shader5`
 * ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads adhere to
   the flatshade_first setting in ``pipe_rasterizer_state``.
 * ``PIPE_CAP_USER_VERTEX_BUFFERS``: Whether the driver supports user vertex
@@ -207,7 +208,7 @@ The integer capabilities:
   PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
 * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
   different sizes for fb color/zs attachments. This controls whether
-  ARB_framebuffer_object is provided.
+  :ext:`GL_ARB_framebuffer_object` is provided.
 * ``PIPE_CAP_VS_LAYER_VIEWPORT``: Whether ``VARYING_SLOT_LAYER`` and
   ``VARYING_SLOT_VIEWPORT`` are supported as vertex shader outputs. Note that
   the viewport will only be used if multiple viewports are exposed.
@@ -270,11 +271,11 @@ The integer capabilities:
 * ``PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE``: The maximum supported vertex stride.
 * ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be
   different than the underlying resource's, as permitted by
-  ARB_texture_view. For example a 2d array texture may be reinterpreted as a
+  :ext:`GL_ARB_texture_view`. For example a 2d array texture may be reinterpreted as a
   cube (array) texture and vice-versa.
 * ``PIPE_CAP_CLIP_HALFZ``: Whether the driver supports the
   pipe_rasterizer_state::clip_halfz being set to true. This is required
-  for enabling ARB_clip_control.
+  for enabling :ext:`GL_ARB_clip_control`.
 * ``PIPE_CAP_POLYGON_OFFSET_CLAMP``: If true, the driver implements support
   for ``pipe_rasterizer_state::offset_clamp``.
 * ``PIPE_CAP_MULTISAMPLE_Z_RESOLVE``: Whether the driver supports blitting
@@ -303,16 +304,16 @@ The integer capabilities:
   textures.
 * ``PIPE_CAP_DEPTH_BOUNDS_TEST``: Whether bounds_test, bounds_min, and
   bounds_max states of pipe_depth_stencil_alpha_state behave according
-  to the GL_EXT_depth_bounds_test specification.
+  to the :ext:`GL_EXT_depth_bounds_test` specification.
 * ``PIPE_CAP_TEXTURE_QUERY_SAMPLES``: Whether the ``TXQS`` opcode is supported
 * ``PIPE_CAP_FORCE_PERSAMPLE_INTERP``: If the driver can force per-sample
   interpolation for all fragment shader inputs if
   pipe_rasterizer_state::force_persample_interp is set. This is only used
-  by GL3-level sample shading (ARB_sample_shading). GL4-level sample shading
-  (ARB_gpu_shader5) doesn't use this. While GL3 hardware has a state for it,
-  GL4 hardware will likely need to emulate it with a shader variant, or by
-  selecting the interpolation weights with a conditional assignment
-  in the shader.
+  by GL3-level sample shading (:ext:`GL_ARB_sample_shading`). GL4-level sample
+  shading (:ext:`GL_ARB_gpu_shader5`) doesn't use this. While GL3 hardware has a
+  state for it, GL4 hardware will likely need to emulate it with a shader
+  variant, or by selecting the interpolation weights with a conditional
+  assignment in the shader.
 * ``PIPE_CAP_SHAREABLE_SHADERS``: Whether shader CSOs can be used by any
   pipe_context.  Important for reducing jank at draw time by letting GL shaders
   linked in one thread be used in another thread without recompiling.
@@ -367,11 +368,13 @@ The integer capabilities:
   rendering or textures.
 * ``PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR``: Implementation uses bounds
   checking on resource accesses by shader if the context is created with
-  PIPE_CONTEXT_ROBUST_BUFFER_ACCESS. See the ARB_robust_buffer_access_behavior
-  extension for information on the required behavior for out of bounds accesses
-  and accesses to unbound resources.
-* ``PIPE_CAP_CULL_DISTANCE``: Whether the driver supports the arb_cull_distance
-  extension and thus implements proper support for culling planes.
+  PIPE_CONTEXT_ROBUST_BUFFER_ACCESS. See the
+  :ext:`GL_ARB_robust_buffer_access_behavior` extension for information on the
+  required behavior for out of bounds accesses and accesses to unbound
+  resources.
+* ``PIPE_CAP_CULL_DISTANCE``: Whether the driver supports the
+  :ext:`GL_ARB_cull_distance` extension and thus implements proper support for
+  culling planes.
 * ``PIPE_CAP_CULL_DISTANCE_NOCOMBINE``: Whether the driver wants to skip
   running the ``nir_lower_clip_cull_distance_arrays`` pass in order to get
   VARYING_SLOT_CULL_DIST0 slot variables.
@@ -401,13 +404,13 @@ The integer capabilities:
   equal interpolation qualifiers.
   Components may overlap, notably when the gaps in an array of dvec3 are
   filled in.
-* ``PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME``: Whether GL_ARB_transform_feedback2
-  is supported, including pausing/resuming queries and having
-  ``count_from_stream_output`` set on indirect draws to implement
-  glDrawTransformFeedback.  Required for OpenGL 4.0.
+* ``PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME``: Whether
+  :ext:`GL_ARB_transform_feedback2` is supported, including pausing/resuming
+  queries and having ``count_from_stream_output`` set on indirect draws to
+  implement glDrawTransformFeedback.  Required for OpenGL 4.0.
 * ``PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS``: Whether interleaved stream
   output mode is able to interleave across buffers. This is required for
-  ARB_transform_feedback3.
+  :ext:`GL_ARB_transform_feedback3`.
 * ``PIPE_CAP_SHADER_CAN_READ_OUTPUTS``: Whether every TGSI shader stage can read
   from the output file.
 * ``PIPE_CAP_FBFETCH``: The number of render targets whose value in the
@@ -459,7 +462,7 @@ The integer capabilities:
 * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports ``TGSI_OPCODE_LOAD`` use
   with constant buffers.
 * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
-  GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
+  :ext:`GL_MESA_tile_raster_order`, using the tile_raster_order_* fields in
   pipe_rasterizer_state.
 * ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined shader
   output resources (images + buffers + fragment outputs). If 0 the state
@@ -509,7 +512,7 @@ The integer capabilities:
 * ``PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE``: Whether
   ``PIPE_CAP_POST_DEPTH_COVERAGE`` works with conservative rasterization.
 * ``PIPE_CAP_CONSERVATIVE_RASTER_INNER_COVERAGE``: Whether
-  inner_coverage from GL_INTEL_conservative_rasterization is supported.
+  inner_coverage from :ext:`GL_INTEL_conservative_rasterization` is supported.
 * ``PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS``: The maximum
   subpixel precision bias in bits during conservative rasterization.
 * ``PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS``: True is the driver supports
@@ -534,7 +537,7 @@ The integer capabilities:
   of pipe_vertex_element::src_offset.
 * ``PIPE_CAP_SURFACE_SAMPLE_COUNT``: Whether the driver
   supports pipe_surface overrides of resource nr_samples. If set, will
-  enable EXT_multisampled_render_to_texture.
+  enable :ext:`GL_EXT_multisampled_render_to_texture`.
 * ``PIPE_CAP_IMAGE_ATOMIC_FLOAT_ADD``: Atomic floating point adds are
   supported on images, buffers, and shared memory.
 * ``PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND``: True if the driver needs blend state to use zero/one instead of destination alpha for RGB/XRGB formats.
@@ -577,7 +580,7 @@ The integer capabilities:
   turn arrays whose contents can be deduced at compile time into constant
   buffer loads, or false if the driver can handle such arrays itself in a more
   efficient manner (such as through nir_opt_large_constants() and nir->constant_data).
-* ``PIPE_CAP_GL_SPIRV``: True if the driver supports ARB_gl_spirv extension.
+* ``PIPE_CAP_GL_SPIRV``: True if the driver supports :ext:`GL_ARB_gl_spirv` extension.
 * ``PIPE_CAP_GL_SPIRV_VARIABLE_POINTERS``: True if the driver supports Variable Pointers in SPIR-V shaders.
 * ``PIPE_CAP_DEMOTE_TO_HELPER_INVOCATION``: True if driver supports demote keyword in GLSL programs.
 * ``PIPE_CAP_TGSI_TG4_COMPONENT_IN_SWIZZLE``: True if driver wants the TG4 component encoded in sampler swizzle rather than as a separate source.
@@ -604,9 +607,9 @@ The integer capabilities:
 * ``PIPE_CAP_VIEWPORT_TRANSFORM_LOWERED``: Driver needs the nir_lower_viewport_transform pass to be enabled. This also means that the gl_Position value is modified and should be lowered for transform feedback, if needed. Defaults to false.
 * ``PIPE_CAP_PSIZ_CLAMPED``: Driver needs for the point size to be clamped. Additionally, the gl_PointSize has been modified and its value should be lowered for transform feedback, if needed. Defaults to false.
 * ``PIPE_CAP_GL_BEGIN_END_BUFFER_SIZE``: Buffer size used to upload vertices for glBegin/glEnd.
-* ``PIPE_CAP_VIEWPORT_SWIZZLE``: Whether pipe_viewport_state::swizzle can be used to specify pre-clipping swizzling of coordinates (see GL_NV_viewport_swizzle).
+* ``PIPE_CAP_VIEWPORT_SWIZZLE``: Whether pipe_viewport_state::swizzle can be used to specify pre-clipping swizzling of coordinates (see :ext:`GL_NV_viewport_swizzle`).
 * ``PIPE_CAP_SYSTEM_SVM``: True if all application memory can be shared with the GPU without explicit mapping.
-* ``PIPE_CAP_VIEWPORT_MASK``: Whether ``TGSI_SEMANTIC_VIEWPORT_MASK`` and ``TGSI_PROPERTY_LAYER_VIEWPORT_RELATIVE`` are supported (see GL_NV_viewport_array2).
+* ``PIPE_CAP_VIEWPORT_MASK``: Whether ``TGSI_SEMANTIC_VIEWPORT_MASK`` and ``TGSI_PROPERTY_LAYER_VIEWPORT_RELATIVE`` are supported (see :ext:`GL_NV_viewport_array2`).
 * ``PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE``: Whether mapping a buffer as unsynchronized from any thread is safe.
 * ``PIPE_CAP_GLSL_ZERO_INIT``: Choose a default zero initialization some GLSL variables. If ``1``, then all GLSL shader variables and gl_FragColor are initialized to zero. If ``2``, then shader out variables are not initialized but function out variables are.
 * ``PIPE_CAP_BLEND_EQUATION_ADVANCED``: Driver supports blend equation advanced without necessarily supporting FBFETCH.
@@ -628,7 +631,7 @@ The integer capabilities:
 * ``PIPE_CAP_MAX_SPARSE_TEXTURE_SIZE``: Maximum 1D/2D/rectangle texture image dimension for a sparse texture.
 * ``PIPE_CAP_MAX_SPARSE_3D_TEXTURE_SIZE``: Maximum 3D texture image dimension for a sparse texture.
 * ``PIPE_CAP_MAX_SPARSE_ARRAY_TEXTURE_LAYERS``: Maximum number of layers in a sparse array texture.
-* ``PIPE_CAP_SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS``: TRUE if there are no restrictions on the allocation of mipmaps in sparse textures and FALSE otherwise. See SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB description in ARB_sparse_texture extension spec.
+* ``PIPE_CAP_SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS``: TRUE if there are no restrictions on the allocation of mipmaps in sparse textures and FALSE otherwise. See SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB description in :ext:`GL_ARB_sparse_texture` extension spec.
 * ``PIPE_CAP_QUERY_SPARSE_TEXTURE_RESIDENCY``: TRUE if shader sparse texture sample instruction could also return the residency information.
 * ``PIPE_CAP_CLAMP_SPARSE_TEXTURE_LOD``: TRUE if shader sparse texture sample instruction support clamp the minimal lod to prevent read from un-committed pages.
 * ``PIPE_CAP_ALLOW_DRAW_OUT_OF_ORDER``: TRUE if the driver allows the "draw out of order" optimization to be enabled. See _mesa_update_allow_draw_out_of_order for more details.
diff --git a/docs/gallium/tgsi.rst b/docs/gallium/tgsi.rst
index 7534c1a4e41..ed5ea76ee92 100644
--- a/docs/gallium/tgsi.rst
+++ b/docs/gallium/tgsi.rst
@@ -899,9 +899,9 @@ XXX doesn't look like most of the opcodes really belong here.
 
 .. opcode:: TXF - Texel Fetch
 
-  As per NV_gpu_program4, extract a single texel from a specified texture
-  image or PIPE_BUFFER resource. The source sampler may not be a CUBE or
-  SHADOW.  *src0* is a
+  As per :ext:`GL_NV_gpu_program4`, extract a single texel from a specified
+  texture image or PIPE_BUFFER resource. The source sampler may not be a
+  CUBE or SHADOW.  *src0* is a
   four-component signed integer vector used to identify the single texel
   accessed. 3 components + level.  If the texture is multisampled, then
   the fourth component indicates the sample, not the mipmap level.
@@ -915,11 +915,11 @@ XXX doesn't look like most of the opcodes really belong here.
 
 .. opcode:: TXQ - Texture Size Query
 
-  As per NV_gpu_program4, retrieve the dimensions of the texture depending on
-  the target. For 1D (width), 2D/RECT/CUBE (width, height), 3D (width, height,
-  depth), 1D array (width, layers), 2D array (width, height, layers).
-  Also return the number of accessible levels (last_level - first_level + 1)
-  in W.
+  As per :ext:`GL_NV_gpu_program4`, retrieve the dimensions of the texture
+  depending on   the target. For 1D (width), 2D/RECT/CUBE (width, height),
+  3D (width, height, depth), 1D array (width, layers), 2D array (width,
+  height, layers).  Also return the number of accessible levels
+  (last_level - first_level + 1) in W.
 
   For components which don't return a resource dimension, their value
   is undefined.
@@ -951,15 +951,15 @@ XXX doesn't look like most of the opcodes really belong here.
 
 .. opcode:: TG4 - Texture Gather
 
-  As per ARB_texture_gather, gathers the four texels to be used in a bi-linear
-  filtering operation and packs them into a single register.  Only works with
-  2D, 2D array, cubemaps, and cubemaps arrays.  For 2D textures, only the
-  addressing modes of the sampler and the top level of any mip pyramid are
-  used. Set W to zero.  It behaves like the TEX instruction, but a filtered
-  sample is not generated. The four samples that contribute to filtering are
-  placed into XYZW in clockwise order, starting with the (u,v) texture
-  coordinate delta at the following locations (-, +), (+, +), (+, -), (-, -),
-  where the magnitude of the deltas are half a texel.
+  As per :ext:`GL_ARB_texture_gather`, gathers the four texels to be used in a
+  bi-linear   filtering operation and packs them into a single register.
+  Only works with 2D, 2D array, cubemaps, and cubemaps arrays.  For 2D
+  textures, only the addressing modes of the sampler and the top level of any
+  mip pyramid are used. Set W to zero.  It behaves like the TEX instruction,
+  but a filtered sample is not generated. The four samples that contribute to
+  filtering are placed into XYZW in clockwise order, starting with the (u,v)
+  texture coordinate delta at the following locations (-, +), (+, +), (+, -),
+  (-, -), where the magnitude of the deltas are half a texel.
 
   PIPE_CAP_TEXTURE_SM5 enhances this instruction to support shadow per-sample
   depth compares, single component selection, and a non-constant offset. It
@@ -3537,7 +3537,7 @@ TGSI_SEMANTIC_VIEWPORT_MASK
 """""""""""""""""""""""""""
 
 A bit mask of viewports to broadcast the current primitive to. See
-GL_NV_viewport_array2 for more details.
+:ext:`GL_NV_viewport_array2` for more details.
 
 
 TGSI_SEMANTIC_TESS_DEFAULT_OUTER_LEVEL
@@ -3666,7 +3666,7 @@ If LOWER_LEFT, the position will be (0,0) at the lower left corner and
 increase upward and rightward.
 
 OpenGL defaults to LOWER_LEFT, and is configurable with the
-GL_ARB_fragment_coord_conventions extension.
+:ext:`GL_ARB_fragment_coord_conventions` extension.
 
 DirectX 9/10 use UPPER_LEFT.
 
@@ -3684,7 +3684,7 @@ rasterization, which is instead controlled by half_pixel_center in the
 rasterizer.
 
 OpenGL defaults to HALF_INTEGER, and is configurable with the
-GL_ARB_fragment_coord_conventions extension.
+:ext:`GL_ARB_fragment_coord_conventions` extension.
 
 DirectX 9 uses INTEGER.
 DirectX 10 uses HALF_INTEGER.
diff --git a/docs/history.rst b/docs/history.rst
index 344a4f00312..5a94c48781e 100644
--- a/docs/history.rst
+++ b/docs/history.rst
@@ -66,8 +66,8 @@ November 2002: Mesa 5.0 is released. It implements the OpenGL 1.4
 specification.
 
 January 2003: Mesa 6.0 is released. It implements the OpenGL 1.5
-specification as well as the GL_ARB_vertex_program and
-GL_ARB_fragment_program extensions.
+specification as well as the :ext:`GL_ARB_vertex_program` and
+:ext:`GL_ARB_fragment_program` extensions.
 
 June 2007: Mesa 7.0 is released, implementing the OpenGL 2.1
 specification and OpenGL Shading Language.
diff --git a/docs/isl/formats.rst b/docs/isl/formats.rst
index 29ccad11463..ba0db87aeb8 100644
--- a/docs/isl/formats.rst
+++ b/docs/isl/formats.rst
@@ -131,29 +131,29 @@ the sRGB colorspace.
 When sampling from a texture, the value returned to the shader is in the linear
 colorspace.  The conversion from sRGB happens as part of sampling. In OpenGL,
 thanks mostly to history, there are various knobs for determining when you
-should or should not encode or decode sRGB.  In 2007, GL_EXT_texture_sRGB added
-support for sRGB texture formats and was included in OpenGL 2.1.  In 2010,
-GL_EXT_texture_sRGB_decode added a flag to allow you to disable texture
-decoding so that the shader received the data still in the sRGB colorspace.
-Then, in 2012, GL_ARB_texture_view came along and made
-GL_EXT_texture_sRGB_decode simultaneously obsolete and very confusing.  Now,
-thanks to the combination of extensions, you can upload a texture as linear,
-create an sRGB view of it and ask that sRGB not be decoded.  What format is it
-in again?
+should or should not encode or decode sRGB.  In 2007, :ext:`GL_EXT_texture_sRGB`
+added support for sRGB texture formats and was included in OpenGL 2.1.  In
+2010, :ext:`GL_EXT_texture_sRGB_decode` added a flag to allow you to disable
+texture decoding so that the shader received the data still in the sRGB
+colorspace. Then, in 2012, :ext:`GL_ARB_texture_view` came along and made
+:ext:`GL_EXT_texture_sRGB_decode` simultaneously obsolete and very confusing.
+Now, thanks to the combination of extensions, you can upload a texture as
+linear, create an sRGB view of it and ask that sRGB not be decoded.  What
+format is it in again?
 
 The situation with render targets is a bit different.  Historically, you got
 your render target from the window system (which is always sRGB) and the spec
 said nothing whatsoever about encoding.  All render targets were sRGB because
 that's how monitors worked and application writers were expected to understand
 that their final rendering needed to be in sRGB.  However, with the advent of
-EXT_framebuffer_object this was no longer true.  Also, sRGB was causing
+:ext:`GL_EXT_framebuffer_object` this was no longer true.  Also, sRGB was causing
 problems with blending because GL was blind to the fact that the output was
 sRGB and blending was occurring in the wrong colorspace. In 2006, a set of
-EXT_framebuffer_sRGB extensions added support (on both the GL and window-system
-sides) for detecting whether a particular framebuffer was in sRGB and
-instructing GL to do the conversion into the sRGB colorspace as the final step
-prior to writing out to the render target.  Enabling sRGB also implied that
-blending would occur in the linear colorspace prior to sRGB conversion and
+:ext:`GL_EXT_framebuffer_sRGB` extensions added support (on both the GL and
+window-system sides) for detecting whether a particular framebuffer was in sRGB
+and instructing GL to do the conversion into the sRGB colorspace as the final
+step prior to writing out to the render target.  Enabling sRGB also implied
+that blending would occur in the linear colorspace prior to sRGB conversion and
 would therefore be more accurate.  When sRGB was added to the OpenGL ES spec in
 3.1, they added the query for sRGB but did not add the flag to allow you to
 turn it on and off.
diff --git a/docs/shading.rst b/docs/shading.rst
index 01c8bc99a00..24e1dfbfea0 100644
--- a/docs/shading.rst
+++ b/docs/shading.rst
@@ -71,9 +71,9 @@ language.
 
 Several GLSL extensions are also supported:
 
--  GL_ARB_draw_buffers
--  GL_ARB_fragment_coord_conventions
--  GL_ARB_shader_bit_encoding
+-  :ext:`GL_ARB_draw_buffers`
+-  :ext:`GL_ARB_fragment_coord_conventions`
+-  :ext:`GL_ARB_shader_bit_encoding`
 
 Unsupported Features
 --------------------
@@ -95,7 +95,8 @@ Implementation Notes
 --------------------
 
 -  Shading language programs are compiled into low-level programs very
-   similar to those of GL_ARB_vertex/fragment_program.
+   similar to those of :ext:`GL_ARB_vertex_program` /
+   :ext:`GL_ARB_fragment_program`.
 -  All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
    float[4] registers.
 -  Float constants and variables are packed so that up to four floats
@@ -142,7 +143,7 @@ After building Mesa, the compiler can be found at
 src/compiler/glsl/glsl_compiler
 
 Here's an example of using the compiler to compile a vertex shader and
-emit GL_ARB_vertex_program-style instructions:
+emit :ext:`GL_ARB_vertex_program`-style instructions:
 
 .. code-block:: console
 
diff --git a/docs/thanks.rst b/docs/thanks.rst
index 7323144e44f..be671bc7876 100644
--- a/docs/thanks.rst
+++ b/docs/thanks.rst
@@ -34,7 +34,7 @@ somewhat dated, unfortunately.
    superseded by SGI SI GLU).
 -  **Holger Waechtler** contributed AMD 3DNow! assembly code which
    accelerates vertex transformation in Mesa 3.1. Holger also
-   implemented the GL_EXT_texture_env_combine extension.
+   implemented the :ext:`GL_EXT_texture_env_combine` extension.
 -  **Jeroen van der Zijp** and **Thorsten Ohl** contributed the Xt/Motif
    widget code.
 -  **John Stone** provided the multi-threading support in Mesa 3.0.
diff --git a/docs/viewperf.rst b/docs/viewperf.rst
index 86fec8c81bc..2c0ac89beaa 100644
--- a/docs/viewperf.rst
+++ b/docs/viewperf.rst
@@ -37,10 +37,8 @@ Catia-03 tests 3, 4, 8
 ~~~~~~~~~~~~~~~~~~~~~~
 
 These tests use features of the
-`GL_NV_fragment_program2 <https://www.opengl.org/registry/specs/NV/fragment_program2.txt>`__
-and
-`GL_NV_vertex_program3 <https://www.opengl.org/registry/specs/NV/vertex_program3.txt>`__
-extensions without checking if the driver supports them.
+:ext:`GL_NV_fragment_program2` and :ext:`GL_NV_vertex_program3` extensions
+without checking if the driver supports them.
 
 When Mesa tries to compile the vertex/fragment programs it generates
 errors (which Viewperf ignores). Subsequent drawing calls become no-ops
@@ -49,9 +47,7 @@ and the rendering is incorrect.
 sw-02 tests 1, 2, 4, 6
 ~~~~~~~~~~~~~~~~~~~~~~
 
-These tests depend on the
-`GL_NV_primitive_restart <https://www.opengl.org/registry/specs/NV/primitive_restart.txt>`__
-extension.
+These tests depend on the :ext:`GL_NV_primitive_restart` extension.
 
 If the Mesa driver doesn't support this extension the rendering will be
 incorrect and the test will fail.
@@ -211,11 +207,11 @@ catia-04
 ~~~~~~~~
 
 One of the catia tests calls wglGetProcAddress() to get some
-GL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and
-some GL_NV_half_float functions (such as glMultiTexCoord3hNV). If the
-extension/function is not supported, wglGetProcAddress() can return
-NULL. Unfortunately, Viewperf doesn't check for null pointers and
-crashes when it later tries to use the pointer.
+:ext:`GL_EXT_direct_state_access` functions (such as
+glBindMultiTextureEXT) and some :ext:`GL_NV_half_float` functions (such
+as glMultiTexCoord3hNV). If the extension/function is not supported,
+wglGetProcAddress() can return NULL. Unfortunately, Viewperf doesn't check
+for null pointers and crashes when it later tries to use the pointer.
 
 Another catia test uses OpenGL 3.1's primitive restart feature. But when
 Viewperf creates an OpenGL context, it doesn't request version 3.1 If
diff --git a/docs/vulkan/dispatch.rst b/docs/vulkan/dispatch.rst
index 3abaab5f02b..1ed093e45e3 100644
--- a/docs/vulkan/dispatch.rst
+++ b/docs/vulkan/dispatch.rst
@@ -257,7 +257,8 @@ the function pointer:
     index into the entrypoint table, not the dispatch table, because the
     rules for when an entrypoint should be exposed are per-entrypoint.  For
     instance, ``vkBindImageMemory2`` is available on Vulkan 1.1 and later but
-    ``vkBindImageMemory2KHR`` is available if VK_KHR_bind_memory2 is enabled.
+    ``vkBindImageMemory2KHR`` is available if :ext:`VK_KHR_bind_memory2` is
+    enabled.
 
  3. A compaction table is used to map from the entrypoint table index to
     the dispatch table index and the function is finally fetched from the
diff --git a/docs/vulkan/renderpass.rst b/docs/vulkan/renderpass.rst
index 44d250cc655..758badc5b93 100644
--- a/docs/vulkan/renderpass.rst
+++ b/docs/vulkan/renderpass.rst
@@ -5,13 +5,14 @@ The Vulkan runtime code in Mesa provides several helpful utilities to make
 managing render passes easier.
 
 
-VK_KHR_create_renderpass2
--------------------------
+:ext:`VK_KHR_create_renderpass2`
+--------------------------------
 
-It is strongly recommended that drivers implement VK_KHR_create_renderpass2
-directly and not bother implementing the old Vulkan 1.0 entrypoints.  If a
-driver does not implement them, the following will be implemented in common
-code in terms of their VK_KHR_create_renderpass2 counterparts:
+It is strongly recommended that drivers implement
+:ext:`VK_KHR_create_renderpass2` directly and not bother implementing the
+old Vulkan 1.0 entrypoints.  If a driver does not implement them, the
+following will be implemented in common code in terms of their
+:ext:`VK_KHR_create_renderpass2` counterparts:
 
  - :cpp:func:`vkCreateRenderPass`
  - :cpp:func:`vkCmdBeginRenderPass`
@@ -34,12 +35,12 @@ that driver doesn't need to do any additional compilation at
 of :cpp:func:`vkCreateRenderPass2` and :cpp:func:`vkDestroyRenderPass`.
 
 
-VK_KHR_dynamic_rendering
-------------------------
+:ext:`VK_KHR_dynamic_rendering`
+-------------------------------
 
 For drivers which don't need to do subpass combining, it is recommended
 that they skip implementing render passes entirely and implement
-VK_KHR_dynamic_rendering instead.  If they choose to do so, the runtime
+:ext:`VK_KHR_dynamic_rendering` instead.  If they choose to do so, the runtime
 will provide the following, implemented in terms of
 :cpp:func:`vkCmdBeginRendering` and :cpp:func:`vkCmdEndRendering`:
 
@@ -66,7 +67,7 @@ Because render passes and subpass indices are also passed into
 :cpp:func:`vkCmdCreateGraphicsPipelines` and
 :cpp:func:`vkCmdExecuteCommands` which we can't implement on the driver's
 behalf, we provide a couple of helpers for getting the render pass
-information in terms of the relevant VK_KHR_dynamic_rendering:
+information in terms of the relevant :ext:`VK_KHR_dynamic_rendering`:
 
 .. doxygenfunction:: vk_get_pipeline_rendering_create_info