docs/viewperf.html

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