This page lists known issues with -SPEC Viewperf 11 +SPEC Viewperf 11 +and SPEC Viewperf 12 when running on Mesa-based drivers.
@@ -40,13 +41,15 @@ These issues have been reported to the SPEC organization in the hope that they'll be fixed in the future. +-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.
-This test creates over 38000 vertex buffer objects. On some systems @@ -59,14 +62,14 @@ either in Viewperf or the Mesa driver. -
These tests use features of the - GL_NV_fragment_program2 and - GL_NV_vertex_program3 extensions without checking if the driver supports them. @@ -79,11 +82,11 @@ Subsequent drawing calls become no-ops and the rendering is incorrect. -
These tests depend on the -GL_NV_primitive_restart extension.
@@ -99,7 +102,7 @@ color. This is probably due to some uninitialized state somewhere. -The lines drawn in this test appear in a random color. @@ -111,7 +114,7 @@ situation, we get a random color. -
This test uses a number of mipmapped textures, but the textures are @@ -172,7 +175,7 @@ However, we have no plans to implement this work-around in Mesa.
-This test makes some unusual calls to glRotate. For example: @@ -204,7 +207,7 @@ and with a semi-random color (between white and black) since GL_FOG is enabled.
-This uses depth testing but there's two problems: @@ -232,6 +235,116 @@ glClear is called so clearing the depth buffer would be a no-op anyway.
++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. +
+ ++Note that Viewperf 12 only runs on 64-bit Windows 7 or later. +
+ ++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. +
+ + ++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. +
+ ++This test generates many GL_INVALID_OPERATION errors in its calls to +glUniform(). +Causes include: +
+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. +
+ +
+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. +
+ + ++This is actually a DX11 test based on Autodesk's Showcase product. +As such, it won't run with Mesa. +
+ +