docs: fix misspellings
Fixed what I noticed; no warranty for exhaustiveness. Signed-off-by: Nathan Kidd <nkidd@opentext.com> Reviewed-by: Brian Paul <brianp@vmware.com>
This commit is contained in:
@@ -19,7 +19,7 @@
|
||||
<p>
|
||||
The SGI OpenGL conformance tests verify correct operation of OpenGL
|
||||
implementations. I, Brian Paul, have been given a copy of the tests
|
||||
for testing Mesa. The tests are not publically available.
|
||||
for testing Mesa. The tests are not publicly available.
|
||||
</p>
|
||||
<p>
|
||||
This file has the latest results of testing Mesa with the OpenGL 1.2
|
||||
|
@@ -206,7 +206,7 @@ exclusively for the older branch.
|
||||
This "CC" syntax for patch nomination will cause patches to automatically be
|
||||
copied to the mesa-stable@ mailing list when you use "git send-email" to send
|
||||
patches to the mesa-dev@ mailing list. Also, if you realize that a commit
|
||||
should be nominate for the stable branch after it has already been commited,
|
||||
should be nominated for the stable branch after it has already been committed,
|
||||
you can send a note directly to the mesa-stable@lists.freedesktop.org where
|
||||
the Mesa stable-branch maintainers will receive it. Be sure to mention the
|
||||
commit ID of the commit of interest (as it appears in the mesa master branch).
|
||||
|
@@ -25,7 +25,7 @@ href="#overview">overview of Mesa's implementation</a>.</p>
|
||||
<h2>1. Complexity of GL Dispatch</h2>
|
||||
|
||||
<p>Every GL application has at least one object called a GL <em>context</em>.
|
||||
This object, which is an implicit parameter to ever GL function, stores all
|
||||
This object, which is an implicit parameter to every GL function, stores all
|
||||
of the GL related state for the application. Every texture, every buffer
|
||||
object, every enable, and much, much more is stored in the context. Since
|
||||
an application can have more than one context, the context to be used is
|
||||
@@ -51,7 +51,7 @@ example, <tt>glFogCoordf</tt> may operate differently depending on whether
|
||||
or not fog is enabled.</p>
|
||||
|
||||
<p>In multi-threaded environments, it is possible for each thread to have a
|
||||
differnt GL context current. This means that poor old <tt>glVertex3fv</tt>
|
||||
different GL context current. This means that poor old <tt>glVertex3fv</tt>
|
||||
has to know which GL context is current in the thread where it is being
|
||||
called.</p>
|
||||
|
||||
@@ -207,13 +207,13 @@ few preprocessor defines.</p>
|
||||
<li>If <tt>GLX_USE_TLS</tt> is defined, method #4 is used.</li>
|
||||
<li>If <tt>HAVE_PTHREAD</tt> is defined, method #3 is used.</li>
|
||||
<li>If <tt>WIN32_THREADS</tt> is defined, method #2 is used.</li>
|
||||
<li>If none of the preceeding are defined, method #1 is used.</li>
|
||||
<li>If none of the preceding are defined, method #1 is used.</li>
|
||||
</ul>
|
||||
|
||||
<p>Two different techniques are used to handle the various different cases.
|
||||
On x86 and SPARC, a macro called <tt>GL_STUB</tt> is used. In the preamble
|
||||
of the assembly source file different implementations of the macro are
|
||||
selected based on the defined preprocessor variables. The assmebly code
|
||||
selected based on the defined preprocessor variables. The assembly code
|
||||
then consists of a series of invocations of the macros such as:
|
||||
|
||||
<blockquote>
|
||||
@@ -242,7 +242,7 @@ first technique, is to insert <tt>#ifdef</tt> within the assembly
|
||||
implementation of each function. This makes the assembly file considerably
|
||||
larger (e.g., 29,332 lines for <tt>glapi_x86-64.S</tt> versus 1,155 lines for
|
||||
<tt>glapi_x86.S</tt>) and causes simple changes to the function
|
||||
implementation to generate many lines of diffs. Since the assmebly files
|
||||
implementation to generate many lines of diffs. Since the assembly files
|
||||
are typically generated by scripts (see <a href="#autogen">below</a>), this
|
||||
isn't a significant problem.</p>
|
||||
|
||||
|
@@ -88,7 +88,7 @@ drivers will be installed to <code>${libdir}/egl</code>.</p>
|
||||
<dd>
|
||||
|
||||
<p>List the platforms (window systems) to support. Its argument is a comma
|
||||
seprated string such as <code>--with-egl-platforms=x11,drm</code>. It decides
|
||||
separated string such as <code>--with-egl-platforms=x11,drm</code>. It decides
|
||||
the platforms a driver may support. The first listed platform is also used by
|
||||
the main library to decide the native platform: the platform the EGL native
|
||||
types such as <code>EGLNativeDisplayType</code> or
|
||||
@@ -223,7 +223,7 @@ the X server directly using (XCB-)DRI2 protocol.</p>
|
||||
<dd>
|
||||
|
||||
<p>This driver is based on Gallium3D. It supports all rendering APIs and
|
||||
hardwares supported by Gallium3D. It is the only driver that supports OpenVG.
|
||||
hardware supported by Gallium3D. It is the only driver that supports OpenVG.
|
||||
The supported platforms are X11, DRM, FBDEV, and GDI.</p>
|
||||
|
||||
<p>This driver comes with its own hardware drivers
|
||||
@@ -273,8 +273,8 @@ longer than the display that creates them.</p>
|
||||
|
||||
<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all
|
||||
display resources should be destroyed. Similarly, when a thread is released
|
||||
throught <code>eglReleaseThread</code>, all current display resources should be
|
||||
released. Another way to destory or release resources is through functions
|
||||
through <code>eglReleaseThread</code>, all current display resources should be
|
||||
released. Another way to destroy or release resources is through functions
|
||||
such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p>
|
||||
|
||||
<p>When a resource that is current to some thread is destroyed, the resource
|
||||
|
@@ -47,7 +47,7 @@ sometimes be useful for debugging end-user issues.
|
||||
<li>MESA_NO_SSE - if set, disables Intel SSE optimizations
|
||||
<li>MESA_DEBUG - if set, error messages are printed to stderr. For example,
|
||||
if the application generates a GL_INVALID_ENUM error, a corresponding error
|
||||
message indicating where the error occured, and possibly why, will be
|
||||
message indicating where the error occurred, and possibly why, will be
|
||||
printed to stderr.<br>
|
||||
If the value of MESA_DEBUG is 'FP' floating point arithmetic errors will
|
||||
generate exceptions.
|
||||
@@ -201,14 +201,14 @@ See src/mesa/state_tracker/st_debug.c for other options.
|
||||
to stderr
|
||||
<li>SOFTPIPE_NO_RAST - if set, rasterization is no-op'd. For profiling purposes.
|
||||
<li>SOFTPIPE_USE_LLVM - if set, the softpipe driver will try to use LLVM JIT for
|
||||
vertex shading procesing.
|
||||
vertex shading processing.
|
||||
</ul>
|
||||
|
||||
|
||||
<h3>LLVMpipe driver environment variables</h3>
|
||||
<ul>
|
||||
<li>LP_NO_RAST - if set LLVMpipe will no-op rasterization
|
||||
<li>LP_DEBUG - a comma-separated list of debug options is acceptec. See the
|
||||
<li>LP_DEBUG - a comma-separated list of debug options is accepted. See the
|
||||
source code for details.
|
||||
<li>LP_PERF - a comma-separated list of options to selectively no-op various
|
||||
parts of the driver. See the source code for details.
|
||||
|
@@ -137,7 +137,7 @@ Just follow the Mesa <a href="install.html">compilation instructions</a>.
|
||||
<h2>1.6 Are there other open-source implementations of OpenGL?</h2>
|
||||
<p>
|
||||
Yes, SGI's <a href="http://oss.sgi.com/projects/ogl-sample/index.html">
|
||||
OpenGL Sample Implemenation (SI)</a> is available.
|
||||
OpenGL Sample Implementation (SI)</a> is available.
|
||||
The SI was written during the time that OpenGL was originally designed.
|
||||
Unfortunately, development of the SI has stagnated.
|
||||
Mesa is much more up to date with modern features and extensions.
|
||||
@@ -353,7 +353,7 @@ That's where Mesa development is discussed.
|
||||
</p>
|
||||
<p>
|
||||
The <a href="http://www.opengl.org/documentation">
|
||||
OpenGL Specification</a> is the bible for OpenGL implemention work.
|
||||
OpenGL Specification</a> is the bible for OpenGL implementation work.
|
||||
You should read it.
|
||||
</p>
|
||||
<p>Most of the Mesa development work involves implementing new OpenGL
|
||||
@@ -375,7 +375,7 @@ For a Gallium3D hardware driver, the r300g, r600g and the i915g are good example
|
||||
</p>
|
||||
<p>The DRI website has more information about writing hardware drivers.
|
||||
The process isn't well document because the Mesa driver interface changes
|
||||
over time, and we seldome have spare time for writing documentation.
|
||||
over time, and we seldom have spare time for writing documentation.
|
||||
That being said, many people have managed to figure out the process.
|
||||
</p>
|
||||
<p>
|
||||
@@ -390,7 +390,7 @@ The <a href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compres
|
||||
indicates that there are intellectual property (IP) and/or patent issues
|
||||
to be dealt with.
|
||||
</p>
|
||||
<p>We've been unsucessful in getting a response from S3 (or whoever owns
|
||||
<p>We've been unsuccessful in getting a response from S3 (or whoever owns
|
||||
the IP nowadays) to indicate whether or not an open source project can
|
||||
implement the extension (specifically the compression/decompression
|
||||
algorithms).
|
||||
|
@@ -16,7 +16,7 @@
|
||||
|
||||
<h1>OpenGL ES</h1>
|
||||
|
||||
<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More informations about
|
||||
<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More information about
|
||||
OpenGL ES can be found at <a href="http://www.khronos.org/opengles/">
|
||||
http://www.khronos.org/opengles/</a>.</p>
|
||||
|
||||
@@ -48,7 +48,7 @@ EGL drivers for your hardware.</p>
|
||||
|
||||
<h3>Dispatch Table</h3>
|
||||
|
||||
<p>OpenGL ES has an additional indirection when dispatching fucntions</p>
|
||||
<p>OpenGL ES has an additional indirection when dispatching functions</p>
|
||||
|
||||
<pre>
|
||||
Mesa: glFoo() --> _mesa_Foo()
|
||||
|
@@ -20,7 +20,7 @@
|
||||
The current version of the OpenVG state tracker implements OpenVG 1.1.
|
||||
</p>
|
||||
<p>
|
||||
More informations about OpenVG can be found at
|
||||
More information about OpenVG can be found at
|
||||
<a href="http://www.khronos.org/openvg/">
|
||||
http://www.khronos.org/openvg/</a> .
|
||||
</p>
|
||||
|
@@ -156,7 +156,7 @@ each time you do a pull.
|
||||
</p>
|
||||
<li>Small changes to master
|
||||
<p>
|
||||
If you are an experienced git user working on substancial modifications,
|
||||
If you are an experienced git user working on substantial modifications,
|
||||
you are probably
|
||||
working on a separate branch and would rebase your branch prior to
|
||||
merging with master.
|
||||
|
@@ -234,7 +234,7 @@ This option is only relevant if EmitHighLevelInstructions is set.
|
||||
|
||||
<dt>EmitComments</dt>
|
||||
<dd>
|
||||
If set, instructions will be annoted with comments to help with debugging.
|
||||
If set, instructions will be annotated with comments to help with debugging.
|
||||
Extra NOP instructions will also be inserted.
|
||||
</dd>
|
||||
</dl>
|
||||
|
@@ -123,7 +123,7 @@ each directory.
|
||||
Currently there's run-time code generation for x86/SSE, PowerPC
|
||||
and Cell SPU.
|
||||
<li><b>tgsi</b> - TG Shader Infrastructure. Code for encoding,
|
||||
manipulating and interpretting GPU programs.
|
||||
manipulating and interpreting GPU programs.
|
||||
<li><b>translate</b> - module for translating vertex data from one format
|
||||
to another.
|
||||
<li><b>util</b> - assorted utilities for arithmetic, hashing, surface
|
||||
|
@@ -14,7 +14,7 @@
|
||||
<iframe src="contents.html"></iframe>
|
||||
<div class="content">
|
||||
|
||||
<h1>Acknowledgments</h1>
|
||||
<h1>Acknowledgements</h1>
|
||||
|
||||
|
||||
The following individuals and groups are to be acknowledged for their
|
||||
|
@@ -107,7 +107,7 @@ for your application.
|
||||
<p>
|
||||
When using Mesa directly or with GLX, it's up to the application
|
||||
writer to create a window with an appropriate colormap. The GLUT
|
||||
toolkit tris to minimize colormap <em>flashing</em> by sharing
|
||||
toolkit tries to minimize colormap <em>flashing</em> by sharing
|
||||
colormaps when possible. Specifically, if the visual and depth of the
|
||||
window matches that of the root window, the root window's colormap
|
||||
will be shared by the Mesa window. Otherwise, a new, private colormap
|
||||
|
Reference in New Issue
Block a user