-<HTML>
-
-<TITLE>Viewperf Issues</TITLE>
-
-<link rel="stylesheet" type="text/css" href="mesa.css"></head>
-
-<BODY>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en">
+<head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8">
+ <title>Viewperf Issues</title>
+ <link rel="stylesheet" type="text/css" href="mesa.css">
+</head>
+<body>
+
+<div class="header">
+ <h1>The Mesa 3D Graphics Library</h1>
+</div>
+
+<iframe src="contents.html"></iframe>
+<div class="content">
<h1>Viewperf Issues</h1>
<p>
This page lists known issues with
<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
+and <a href="https://www.spec.org/gwpg/gpc.static/vp12info.html" target="_main">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
-<h2>sw-02 tests 1, 2, 4, 6</h2>
+<h3>sw-02 tests 1, 2, 4, 6</h3>
<p>
These tests depend on the
-<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>
-<h2>Maya-03 test 2</h2>
+<h3>Maya-03 test 2</h3>
<p>
This test makes some unusual calls to glRotate. For example:
</p>
-</BODY>
-</HTML>
+<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>