docs/viewperf.rst

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