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