Viewperf Issues
This page lists known issues with 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
+Catia-03 test 2
This test creates over 38000 vertex buffer objects. On some systems @@ -51,7 +62,7 @@ either in Viewperf or the Mesa driver. -
Catia-03 tests 3, 4, 8
+Catia-03 tests 3, 4, 8
These tests use features of the @@ -71,7 +82,7 @@ Subsequent drawing calls become no-ops and the rendering is incorrect. -
sw-02 tests 1, 2, 4, 6
+sw-02 tests 1, 2, 4, 6
These tests depend on the @@ -91,7 +102,7 @@ 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. @@ -103,7 +114,7 @@ situation, we get a random color. -
Lightwave-01 test 3
+Lightwave-01 test 3
This test uses a number of mipmapped textures, but the textures are @@ -164,7 +175,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: @@ -196,5 +207,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. +
+ + +