docs/viewperf.html

   1 <HTML>
   2
   3 <TITLE>Viewperf Issues</TITLE>
   4
   5 <link rel="stylesheet" type="text/css" href="mesa.css"></head>
   6
   7 <BODY>
   8
   9 <h1>Viewperf Issues</h1>
  10
  11 <p>
  12 This page lists known issues with
  13 <a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
  14 when running on Mesa-based drivers.
  15 </p>
  16
  17 <p>
  18 The Viewperf data sets are basically GL API traces that are recorded from
  19 CAD applications, then replayed in the Viewperf framework.
  20 </p>
  21
  22 <p>
  23 The primary problem with these traces is they blindly use features and
  24 OpenGL extensions that were supported by the OpenGL driver when the trace
  25 was recorded,
  26 but there's no checks to see if those features are supported by the driver
  27 when playing back the traces with Viewperf.
  28 </p>
  29
  30 <p>
  31 These issues have been reported to the SPEC organization in the hope that
  32 they'll be fixed in the future.
  33 </p>
  34
  35 <p>
  36 Some of the Viewperf tests use a lot of memory.
  37 At least 2GB of RAM is recommended.
  38 </p>
  39
  40
  41 <h2>Catia-03 test 2</h2>
  42
  43 <p>
  44 This test creates over 38000 vertex buffer objects.  On some systems
  45 this can exceed the maximum number of buffer allocations.  Mesa
  46 generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
  47 does no error checking and continues.  When this happens, some drawing
  48 commands become no-ops.  This can also eventually lead to a segfault
  49 either in Viewperf or the Mesa driver.
  50 </p>
  51
  52
  53
  54 <h2>Catia-03 tests 3, 4, 8</h2>
  55
  56 <p>
  57 These tests use features of the
  58 <a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
  59 target="_main">
  60 GL_NV_fragment_program2</a> and
  61 <a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
  62 target="_main">
  63 GL_NV_vertex_program3</a> extensions without checking if the driver supports
  64 them.
  65 </p>
  66 <p>
  67 When Mesa tries to compile the vertex/fragment programs it generates errors
  68 (which Viewperf ignores).
  69 Subsequent drawing calls become no-ops and the rendering is incorrect.
  70 </p>
  71
  72
  73
  74 <h2>sw-02 tests 1, 2, 4, 6</h2>
  75
  76 <p>
  77 These tests depend on the
  78 <a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
  79 target="_main">GL_NV_primitive_restart</a> extension.
  80 </p>
  81
  82 <p>
  83 If the Mesa driver doesn't support this extension the rendering will
  84 be incorrect and the test will fail.
  85 </p>
  86
  87 <p>
  88 Also, the color of the line drawings in test 2 seem to appear in a random
  89 color.  This is probably due to some uninitialized state somewhere.
  90 </p>
  91
  92
  93
  94 <h2>sw-02 test 6</h2>
  95
  96 <p>
  97 The lines drawn in this test appear in a random color.
  98 That's because texture mapping is enabled when the lines are drawn, but no
  99 texture image is defined (glTexImage2D() is called with pixels=NULL).
 100 Since GL says the contents of the texture image are undefined in that
 101 situation, we get a random color.
 102 </p>
 103
 104
 105
 106 <h2>Lightwave-01 test 3</h2>
 107
 108 <p>
 109 This test uses a number of mipmapped textures, but the textures are
 110 incomplete because the last/smallest mipmap level (1 x 1 pixel) is
 111 never specified.
 112 </p>
 113
 114 <p>
 115 A trace captured with
 116 <a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
 117 shows this sequences of calls like this:
 118
 119 <pre>
 120 2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
 121 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))
 122 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))
 123 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))
 124 [...]
 125 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))
 126 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))
 127 2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
 128 2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
 129 2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
 130 2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
 131 </pre>
 132
 133 <p>
 134 Note that one would expect call 2514 to be glTexImage(level=9, width=1,
 135 height=1) but it's not there.
 136 </p>
 137
 138 <p>
 139 The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
 140 GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
 141 </p>
 142
 143 <p>
 144 Later, these incomplete textures are bound before drawing calls.
 145 According to the GL specification, if a fragment program or fragment shader
 146 is being used, the sampler should return (0,0,0,1) ("black") when sampling
 147 from an incomplete texture.
 148 This is what Mesa does and the resulting rendering is darker than it should
 149 be.
 150 </p>
 151
 152 <p>
 153 It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
 154 and returns (1,1,1,1) (white) which causes the rendering to appear brighter
 155 and match the reference image (however, AMD's rendering is <em>much</em>
 156 brighter than NVIDIA's).
 157 </p>
 158
 159 <p>
 160 If the fallback texture created in _mesa_get_fallback_texture() is
 161 initialized to be full white instead of full black the rendering appears
 162 correct.
 163 However, we have no plans to implement this work-around in Mesa.
 164 </p>
 165
 166
 167 <h2>Maya-03 test 2</h2>
 168
 169 <p>
 170 This test makes some unusual calls to glRotate.  For example:
 171 </p>
 172 <pre>
 173 glRotate(50, 50, 50, 1);
 174 glRotate(100, 100, 100, 1);
 175 glRotate(52, 52, 52, 1);
 176 </pre>
 177 <p>
 178 These unusual values lead to invalid modelview matrices.
 179 For example, the last glRotate command above produces this matrix with Mesa:
 180 <pre>
 181 1.08536e+24 2.55321e-23 -0.000160389 0
 182 5.96937e-25 1.08536e+24 103408 0
 183 103408 -0.000160389 1.74755e+09 0
 184 0 0 0 nan
 185 </pre>
 186 and with NVIDIA's OpenGL:
 187 <pre>
 188 1.4013e-45 0 -nan 0
 189 0 1.4013e-45 1.4013e-45 0
 190 1.4013e-45 -nan 1.4013e-45 0
 191 0 0 0 1.4013e-45
 192 </pre>
 193 <p>
 194 This causes the object in question to be drawn in a strange orientation
 195 and with a semi-random color (between white and black) since GL_FOG is enabled.
 196 </p>
 197
 198
 199 </BODY>
 200 </HTML>