gitlab-ci: fix testing whether a variable with a given name is set or not
[mesa.git] / docs / dispatch.rst
index 4fcce5ac88e48583e4eab50968514eac3212cc31..6b808597310ffd16e5e1e4eac1b667da67f5927f 100644 (file)
@@ -5,7 +5,7 @@ Several factors combine to make efficient dispatch of OpenGL functions
 fairly complicated. This document attempts to explain some of the issues
 and introduce the reader to Mesa's implementation. Readers already
 familiar with the issues around GL dispatch can safely skip ahead to the
-`overview of Mesa's implementation <#overview>`__.
+:ref:`overview of Mesa's implementation <overview>`.
 
 1. Complexity of GL Dispatch
 ----------------------------
@@ -162,7 +162,7 @@ dispatch routines are very short, and it is trivial to create optimal
 assembly language versions. The amount of optimization provided by using
 assembly stubs varies from platform to platform and application to
 application. However, by using the assembly stubs, many platforms can
-use an additional space optimization (see `below <#fixedsize>`__).
+use an additional space optimization (see :ref:`below <fixedsize>`).
 
 The biggest hurdle to creating assembly stubs is handling the various
 ways that the dispatch table pointer can be accessed. There are four
@@ -219,8 +219,8 @@ implementation of each function. This makes the assembly file
 considerably larger (e.g., 29,332 lines for ``glapi_x86-64.S`` versus
 1,155 lines for ``glapi_x86.S``) and causes simple changes to the
 function implementation to generate many lines of diffs. Since the
-assembly files are typically generated by scripts (see
-`below <#autogen>`__), this isn't a significant problem.
+assembly files are typically generated by scripts, this isn't a
+significant problem.
 
 Once a new assembly file is created, it must be inserted in the build
 system. There are two steps to this. The file must first be added to