Viewperf Issues

This page lists known issues with -SPEC Viewperf 11 +SPEC Viewperf 11 +and SPEC Viewperf 12 when running on Mesa-based drivers.

@@ -32,13 +41,15 @@ These issues have been reported to the SPEC organization in the hope that they'll be fixed in the future.

Viewperf 11

-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.

Catia-03 test 2

This test creates over 38000 vertex buffer objects. On some systems @@ -51,17 +62,14 @@ either in Viewperf or the Mesa driver. -

Catia-03 tests 3, 4, 8

These tests use features of the - -GL_NV_fragment_program2 and - -GL_NV_vertex_program3 extensions without checking if the driver supports -them. +GL_NV_fragment_program2 +and +GL_NV_vertex_program3 +extensions without checking if the driver supports them.

When Mesa tries to compile the vertex/fragment programs it generates errors @@ -71,12 +79,12 @@ Subsequent drawing calls become no-ops and the rendering is incorrect. -

sw-02 tests 1, 2, 4, 6

These tests depend on the -GL_NV_primitive_restart extension. +GL_NV_primitive_restart +extension.

@@ -84,9 +92,14 @@ If the Mesa driver doesn't support this extension the rendering will be incorrect and the test will fail.

+Also, the color of the line drawings in test 2 seem to appear in a random +color. This is probably due to some uninitialized state somewhere. +

sw-02 test 6

+ +

sw-02 test 6

The lines drawn in this test appear in a random color. @@ -98,7 +111,7 @@ situation, we get a random color. -

Lightwave-01 test 3

This test uses a number of mipmapped textures, but the textures are @@ -108,7 +121,7 @@ never specified.

A trace captured with -API trace +API trace shows this sequences of calls like this:

@@ -159,7 +172,7 @@ However, we have no plans to implement this work-around in Mesa.
 
 
 
-Maya-03 test 2
+Maya-03 test 2
 
 
 This test makes some unusual calls to glRotate.  For example:
@@ -173,17 +186,17 @@ glRotate(52, 52, 52, 1);
 These unusual values lead to invalid modelview matrices.
 For example, the last glRotate command above produces this matrix with Mesa:
 
-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
 
 and with NVIDIA's OpenGL:
 -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
 
 
 This causes the object in question to be drawn in a strange orientation
@@ -191,5 +204,144 @@ and with a semi-random color (between white and black) since GL_FOG is enabled.
 
 
 
-
-
+Proe-05 test 1
+
+
+This uses depth testing but there's two problems:
+

+The glXChooseFBConfig() call doesn't request a depth buffer
+
The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer
+
+
+If the chosen visual does not have a depth buffer, you'll see the wireframe
+car model but it won't be rendered correctly.
+
+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.
+
+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.
+
+
+
+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.
+
+
+
+Proe-05 test 6
+
+
+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.
+
+
+
+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.
+
+
+
+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.
+
+
+Viewperf 12
+
+
+Note that Viewperf 12 only runs on 64-bit Windows 7 or later.
+
+
+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.
+
+
+
+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.
+
+
+
+energy-01
+
+
+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.
+
+
+maya-04
+
+
+This test generates many GL_INVALID_OPERATION errors in its calls to
+glUniform().
+Causes include:
+

+ Trying to set float uniforms with glUniformi()
+
 Trying to set float uniforms with glUniform3f()
+
 Trying to set matrix uniforms with glUniform() instead of glUniformMatrix().
+
+
+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.
+
+
+medical-01
+
+
+This test uses a single GLSL fragment shader which contains a GLSL 1.20
+array initializer statement, but it neglects to specify
+#version 120 at the top of the shader code.
+So, the shader does not compile and all that's rendered is plain white polygons.
+
+
+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.
+
+
+
+showcase-01
+
+
+This is actually a DX11 test based on Autodesk's Showcase product.
+As such, it won't run with Mesa.
+
+
+
+