1Viewperf Issues 2=============== 3 4This page lists known issues with `SPEC Viewperf 511 <https://gwpg.spec.org/benchmarks/benchmark/specviewperf-11/>`__ and 6`SPEC Viewperf 712 <https://gwpg.spec.org/benchmarks/benchmark/specviewperf-12/>`__ when 8running on Mesa-based drivers. 9 10The Viewperf data sets are basically GL API traces that are recorded 11from CAD applications, then replayed in the Viewperf framework. 12 13The primary problem with these traces is they blindly use features and 14OpenGL extensions that were supported by the OpenGL driver when the 15trace was recorded, but there's no checks to see if those features are 16supported by the driver when playing back the traces with Viewperf. 17 18These issues have been reported to the SPEC organization in the hope 19that they'll be fixed in the future. 20 21Viewperf 11 22----------- 23 24Some of the Viewperf 11 tests use a lot of memory. At least 2GB of RAM 25is recommended. 26 27Catia-03 test 2 28~~~~~~~~~~~~~~~ 29 30This test creates over 38000 vertex buffer objects. On some systems this 31can exceed the maximum number of buffer allocations. Mesa generates 32GL_OUT_OF_MEMORY errors in this situation, but Viewperf does no error 33checking and continues. When this happens, some drawing commands become 34no-ops. This can also eventually lead to a segfault either in Viewperf 35or the Mesa driver. 36 37Catia-03 tests 3, 4, 8 38~~~~~~~~~~~~~~~~~~~~~~ 39 40These tests use features of the 41:ext:`GL_NV_fragment_program2` and :ext:`GL_NV_vertex_program3` extensions 42without checking if the driver supports them. 43 44When Mesa tries to compile the vertex/fragment programs it generates 45errors (which Viewperf ignores). Subsequent drawing calls become no-ops 46and the rendering is incorrect. 47 48sw-02 tests 1, 2, 4, 6 49~~~~~~~~~~~~~~~~~~~~~~ 50 51These tests depend on the :ext:`GL_NV_primitive_restart` extension. 52 53If the Mesa driver doesn't support this extension the rendering will be 54incorrect and the test will fail. 55 56Also, the color of the line drawings in test 2 seem to appear in a 57random color. This is probably due to some uninitialized state 58somewhere. 59 60sw-02 test 6 61~~~~~~~~~~~~ 62 63The lines drawn in this test appear in a random color. That's because 64texture mapping is enabled when the lines are drawn, but no texture 65image is defined (glTexImage2D() is called with pixels=NULL). Since GL 66says the contents of the texture image are undefined in that situation, 67we get a random color. 68 69Lightwave-01 test 3 70~~~~~~~~~~~~~~~~~~~ 71 72This test uses a number of mipmapped textures, but the textures are 73incomplete because the last/smallest mipmap level (1 x 1 pixel) is never 74specified. 75 76A trace captured with `API 77trace <https://github.com/apitrace/apitrace>`__ shows this sequences of 78calls like this: 79 80:: 81 82 2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) 83 2505 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA, width = 512, height = 512, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT, pixels = blob(1572864)) 84 2506 glTexImage2D(target = GL_TEXTURE_2D, level = 1, internalformat = GL_RGBA, width = 256, height = 256, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT, pixels = blob(393216)) 85 2507 glTexImage2D(target = GL_TEXTURE_2D, level = 2, internalformat = GL_RGBA, width = 128, height = 128, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT, pixels = blob(98304)) 86 [...] 87 2512 glTexImage2D(target = GL_TEXTURE_2D, level = 7, internalformat = GL_RGBA, width = 4, height = 4, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT, pixels = blob(96)) 88 2513 glTexImage2D(target = GL_TEXTURE_2D, level = 8, internalformat = GL_RGBA, width = 2, height = 2, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT, pixels = blob(24)) 89 2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) 90 2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) 91 2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) 92 2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 93 94Note that one would expect call 2514 to be glTexImage(level=9, width=1, 95height=1) but it's not there. 96 97The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's 98GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. 99 100Later, these incomplete textures are bound before drawing calls. 101According to the GL specification, if a fragment program or fragment 102shader is being used, the sampler should return (0,0,0,1) ("black") when 103sampling from an incomplete texture. This is what Mesa does and the 104resulting rendering is darker than it should be. 105 106It appears that NVIDIA's driver (and possibly AMD's driver) detects this 107case and returns (1,1,1,1) (white) which causes the rendering to appear 108brighter and match the reference image (however, AMD's rendering is 109*much* brighter than NVIDIA's). 110 111If the fallback texture created in \_mesa_get_fallback_texture() is 112initialized to be full white instead of full black the rendering appears 113correct. However, we have no plans to implement this work-around in 114Mesa. 115 116Maya-03 test 2 117~~~~~~~~~~~~~~ 118 119This test makes some unusual calls to glRotate. For example: 120 121.. code-block:: c 122 123 glRotate(50, 50, 50, 1); 124 glRotate(100, 100, 100, 1); 125 glRotate(52, 52, 52, 1); 126 127These unusual values lead to invalid modelview matrices. For example, 128the last glRotate command above produces this matrix with Mesa: 129 130.. math:: 131 132 \begin{matrix} 133 1.08536 \times 10^{24} & 2.55321 \times 10^{-23} & -0.000160389 & 0\\ 134 5.96937 \times 10^{25} & 1.08536 \times 10^{24} & 103408 & 0\\ 135 103408 & -0.000160389 & 1.74755\times 10^{9} & 0\\ 136 0 & 0 & 0 & nan 137 \end{matrix} 138 139and with NVIDIA's OpenGL: 140 141.. math:: 142 143 \begin{matrix} 144 1.4013 \times 10^{-45} & 0 & -nan & 0\\ 145 0 & 1.4013 \times 10^{-45} & 1.4013 \times 10^{-45} & 0\\ 146 1.4013 \times 10^{-45} & -nan & 1.4013 \times 10^{-45} & 0\\ 147 0 & 0 & 0 & 1.4013 \times 10^{-45} 148 \end{matrix} 149 150This causes the object in question to be drawn in a strange orientation 151and with a semi-random color (between white and black) since GL_FOG is 152enabled. 153 154Proe-05 test 1 155~~~~~~~~~~~~~~ 156 157This uses depth testing but there's two problems: 158 159#. The glXChooseFBConfig() call doesn't request a depth buffer 160#. The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the 161 depth buffer 162 163If the chosen visual does not have a depth buffer, you'll see the 164wireframe car model but it won't be rendered correctly. 165 166If (by luck) the chosen visual has a depth buffer, its initial contents 167will be undefined so you may or may not see parts of the model. 168 169Interestingly, with NVIDIA's driver most visuals happen to have a depth 170buffer and apparently the contents are initialized to 1.0 by default so 171this test just happens to work with their drivers. 172 173Finally, even if a depth buffer was requested and the 174glClear(GL_COLOR_BUFFER_BIT) calls were changed to 175glClear(GL_COLOR_BUFFER_BIT \| GL_DEPTH_BUFFER_BIT) the problem still 176wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when glClear is 177called so clearing the depth buffer would be a no-op anyway. 178 179Proe-05 test 6 180~~~~~~~~~~~~~~ 181 182This test draws an engine model with a two-pass algorithm. The first 183pass is drawn with polygon stipple enabled. The second pass is drawn 184without polygon stipple but with blending and GL_DEPTH_FUNC=GL_LEQUAL. 185If either of the two passes happen to use a software fallback of some 186sort, the Z values of fragments may be different between the two passes. 187This leads to incorrect rendering. 188 189For example, the VMware SVGA Gallium driver uses a special semi-fallback 190path for drawing with polygon stipple. Since the two passes are rendered 191with different vertex transformation implementations, the rendering 192doesn't appear as expected. Setting the SVGA_FORCE_SWTNL environment 193variable to 1 will force the driver to use the software vertex path all 194the time and clears up this issue. 195 196According to the OpenGL invariance rules, there's no guarantee that the 197pixels produced by these two rendering states will match. To achieve 198invariance, both passes should enable polygon stipple and blending with 199appropriate patterns/modes to ensure the same fragments are produced in 200both passes. 201 202Viewperf 12 203----------- 204 205Note that Viewperf 12 only runs on 64-bit Windows 7 or later. 206 207catia-04 208~~~~~~~~ 209 210One of the catia tests calls wglGetProcAddress() to get some 211:ext:`GL_EXT_direct_state_access` functions (such as 212glBindMultiTextureEXT) and some :ext:`GL_NV_half_float` functions (such 213as glMultiTexCoord3hNV). If the extension/function is not supported, 214wglGetProcAddress() can return NULL. Unfortunately, Viewperf doesn't check 215for null pointers and crashes when it later tries to use the pointer. 216 217Another catia test uses OpenGL 3.1's primitive restart feature. But when 218Viewperf creates an OpenGL context, it doesn't request version 3.1 If 219the driver returns version 3.0 or earlier all the calls related to 220primitive restart generate an OpenGL error. Some of the rendering is 221then incorrect. 222 223energy-01 224~~~~~~~~~ 225 226This test creates a 3D luminance texture of size 1K x 1K x 1K. If the 227OpenGL driver/device doesn't support a texture of this size the 228glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY 229and all that's rendered is plain white polygons. Ideally, the test would 230use a proxy texture to determine the max 3D texture size. But it does 231not do that. 232 233maya-04 234~~~~~~~ 235 236This test generates many GL_INVALID_OPERATION errors in its calls to 237glUniform(). Causes include: 238 239- Trying to set float uniforms with glUniformi() 240- Trying to set float uniforms with glUniform3f() 241- Trying to set matrix uniforms with glUniform() instead of 242 glUniformMatrix(). 243 244Apparently, the indexes returned by glGetUniformLocation() were 245hard-coded into the application trace when it was created. Since 246different implementations of glGetUniformLocation() may return different 247values for any given uniform name, subsequent calls to glUniform() will 248be invalid since they refer to the wrong uniform variables. This causes 249many OpenGL errors and leads to incorrect rendering. 250 251medical-01 252~~~~~~~~~~ 253 254This test uses a single GLSL fragment shader which contains a GLSL 1.20 255array initializer statement, but it neglects to specify ``#version 120`` 256at the top of the shader code. So, the shader does not compile and all 257that's rendered is plain white polygons. 258 259Also, the test tries to create a very large 3D texture that may exceed 260the device driver's limit. When this happens, the glTexImage3D call 261fails and all that's rendered is a white box. 262 263showcase-01 264~~~~~~~~~~~ 265 266This is actually a DX11 test based on Autodesk's Showcase product. As 267such, it won't run with Mesa. 268