<body>
<div class="header">
- <h1>The Mesa 3D Graphics Library</h1>
+ The Mesa 3D Graphics Library
</div>
<iframe src="contents.html"></iframe>
<p>
This page lists known issues with
-<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
+<a href="https://www.spec.org/gwpg/gpc.static/vp11info.html">SPEC Viewperf 11</a>
+and <a href="https://www.spec.org/gwpg/gpc.static/vp12info.html">SPEC Viewperf 12</a>
when running on Mesa-based drivers.
</p>
they'll be fixed in the future.
</p>
+<h2><u>Viewperf 11</u></h2>
+
<p>
-Some of the Viewperf tests use a lot of memory.
+Some of the Viewperf 11 tests use a lot of memory.
At least 2GB of RAM is recommended.
</p>
-<h2>Catia-03 test 2</h2>
+<h3>Catia-03 test 2</h3>
<p>
This test creates over 38000 vertex buffer objects. On some systems
-<h2>Catia-03 tests 3, 4, 8</h2>
+<h3>Catia-03 tests 3, 4, 8</h3>
<p>
These tests use features of the
-<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
-target="_main">
-GL_NV_fragment_program2</a> and
-<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
-target="_main">
-GL_NV_vertex_program3</a> extensions without checking if the driver supports
-them.
+<a href="https://www.opengl.org/registry/specs/NV/fragment_program2.txt">GL_NV_fragment_program2</a>
+and
+<a href="https://www.opengl.org/registry/specs/NV/vertex_program3.txt">GL_NV_vertex_program3</a>
+extensions without checking if the driver supports them.
</p>
<p>
When Mesa tries to compile the vertex/fragment programs it generates errors
-<h2>sw-02 tests 1, 2, 4, 6</h2>
+<h3>sw-02 tests 1, 2, 4, 6</h3>
<p>
These tests depend on the
-<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
-target="_main">GL_NV_primitive_restart</a> extension.
+<a href="https://www.opengl.org/registry/specs/NV/primitive_restart.txt">GL_NV_primitive_restart</a>
+extension.
</p>
<p>
-<h2>sw-02 test 6</h2>
+<h3>sw-02 test 6</h3>
<p>
The lines drawn in this test appear in a random color.
-<h2>Lightwave-01 test 3</h2>
+<h3>Lightwave-01 test 3</h3>
<p>
This test uses a number of mipmapped textures, but the textures are
<p>
A trace captured with
-<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
+<a href="https://github.com/apitrace/apitrace">API trace</a>
shows this sequences of calls like this:
<pre>
</p>
-<h2>Maya-03 test 2</h2>
+<h3>Maya-03 test 2</h3>
<p>
This test makes some unusual calls to glRotate. For example:
These unusual values lead to invalid modelview matrices.
For example, the last glRotate command above produces this matrix with Mesa:
<pre>
-1.08536e+24 2.55321e-23 -0.000160389 0
-5.96937e-25 1.08536e+24 103408 0
-103408 -0.000160389 1.74755e+09 0
-0 0 0 nan
+1.08536e+24 2.55321e-23 -0.000160389 0
+5.96937e-25 1.08536e+24 103408 0
+103408 -0.000160389 1.74755e+09 0
+0 0 0 nan
</pre>
and with NVIDIA's OpenGL:
<pre>
-1.4013e-45 0 -nan 0
-0 1.4013e-45 1.4013e-45 0
-1.4013e-45 -nan 1.4013e-45 0
-0 0 0 1.4013e-45
+1.4013e-45 0 -nan 0
+0 1.4013e-45 1.4013e-45 0
+1.4013e-45 -nan 1.4013e-45 0
+0 0 0 1.4013e-45
</pre>
<p>
This causes the object in question to be drawn in a strange orientation
and with a semi-random color (between white and black) since GL_FOG is enabled.
</p>
+
+<h3>Proe-05 test 1</h3>
+
+<p>
+This uses depth testing but there's two problems:
+<ol>
+<li>The glXChooseFBConfig() call doesn't request a depth buffer
+<li>The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer
+</ol>
+<p>
+If the chosen visual does not have a depth buffer, you'll see the wireframe
+car model but it won't be rendered correctly.
+</p>
+If (by luck) the chosen visual has a depth buffer, its initial contents
+will be undefined so you may or may not see parts of the model.
+<p>
+Interestingly, with NVIDIA's driver most visuals happen to have a depth buffer
+and apparently the contents are initialized to 1.0 by default so this test
+just happens to work with their drivers.
+</p>
+
+<p>
+Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT)
+calls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
+the problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when
+glClear is called so clearing the depth buffer would be a no-op anyway.
+</p>
+
+
+<h3>Proe-05 test 6</h3>
+
+<p>
+This test draws an engine model with a two-pass algorithm.
+The first pass is drawn with polygon stipple enabled.
+The second pass is drawn without polygon stipple but with blending
+and GL_DEPTH_FUNC=GL_LEQUAL.
+If either of the two passes happen to use a software fallback of some
+sort, the Z values of fragments may be different between the two passes.
+This leads to incorrect rendering.
+</p>
+
+<p>
+For example, the VMware SVGA gallium driver uses a special semi-fallback path
+for drawing with polygon stipple.
+Since the two passes are rendered with different vertex transformation
+implementations, the rendering doesn't appear as expected.
+Setting the SVGA_FORCE_SWTNL environment variable to 1 will force the
+driver to use the software vertex path all the time and clears up this issue.
+</p>
+
+<p>
+According to the OpenGL invariance rules, there's no guarantee that
+the pixels produced by these two rendering states will match.
+To achieve invariance, both passes should enable polygon stipple and
+blending with appropriate patterns/modes to ensure the same fragments
+are produced in both passes.
+</p>
+
+<h2><u>Viewperf 12</u></h2>
+
+<p>
+Note that Viewperf 12 only runs on 64-bit Windows 7 or later.
+</p>
+
+<h3>catia-04</h3>
+
+<p>
+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.
+</p>
+
+<p>
+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 the driver returns version 3.0 or earlier all the calls related to primitive
+restart generate an OpenGL error.
+Some of the rendering is then incorrect.
+</p>
+
+
+<h3>energy-01</h3>
+
+<p>
+This test creates a 3D luminance texture of size 1K x 1K x 1K.
+If the OpenGL driver/device doesn't support a texture of this size
+the glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY
+and all that's rendered is plain white polygons.
+Ideally, the test would use a proxy texture to determine the max 3D
+texture size. But it does not do that.
+</p>
+
+<h3>maya-04</h3>
+
+<p>
+This test generates many GL_INVALID_OPERATION errors in its calls to
+glUniform().
+Causes include:
+<ul>
+<li> Trying to set float uniforms with glUniformi()
+<li> Trying to set float uniforms with glUniform3f()
+<li> Trying to set matrix uniforms with glUniform() instead of glUniformMatrix().
+</ul>
+<p>
+Apparently, the indexes returned by glGetUniformLocation() were hard-coded
+into the application trace when it was created.
+Since different implementations of glGetUniformLocation() may return different
+values for any given uniform name, subsequent calls to glUniform() will be
+invalid since they refer to the wrong uniform variables.
+This causes many OpenGL errors and leads to incorrect rendering.
+</p>
+
+<h3>medical-01</h3>
+
+<p>
+This test uses a single GLSL fragment shader which contains a GLSL 1.20
+array initializer statement, but it neglects to specify
+<code>#version 120</code> at the top of the shader code.
+So, the shader does not compile and all that's rendered is plain white polygons.
+</p>
+<p>
+Also, the test tries to create a very large 3D texture that may exceed
+the device driver's limit.
+When this happens, the glTexImage3D call fails and all that's rendered is
+a white box.
+</p>
+
+
+<h3>showcase-01</h3>
+
+<p>
+This is actually a DX11 test based on Autodesk's Showcase product.
+As such, it won't run with Mesa.
+</p>
+
+
</div>
</body>
</html>
projects / mesa.git / blobdiff