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
  36
  37 <h2>Catia-03 test 2</h2>
  38
  39 <p>
  40 This test creates over 38000 vertex buffer objects.  On some systems
  41 this can exceed the maximum number of buffer allocations.  Mesa
  42 generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
  43 does no error checking and continues.  When this happens, some drawing
  44 commands become no-ops.  This can also eventually lead to a segfault
  45 either in Viewperf or the Mesa driver.
  46 </p>
  47
  48
  49
  50 <h2>Catia-03 tests 3, 4, 8</h2>
  51
  52 <p>
  53 These tests use features of the
  54 <a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
  55 target="_main">
  56 GL_NV_fragment_program2</a> and
  57 <a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
  58 target="_main">
  59 GL_NV_vertex_program3</a> extensions without checking if the driver supports
  60 them.
  61 </p>
  62 <p>
  63 When Mesa tries to compile the vertex/fragment programs it generates errors
  64 (which Viewperf ignores).
  65 Subsequent drawing calls become no-ops and the rendering is incorrect.
  66 </p>
  67
  68
  69
  70 <h2>sw-02 tests 1, 2, 4</h2>
  71
  72 <p>
  73 These tests depend on the
  74 <a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
  75 target="_main">GL_NV_primitive_restart</a> extension.
  76 </p>
  77
  78 <p>
  79 If the Mesa driver doesn't support this extension the rendering will
  80 be incorrect and the test will fail.
  81 </p>
  82
  83
  84 <h2>Lightwave-01 test 3</h2>
  85
  86 <p>
  87 This test uses a number of mipmapped textures, but the textures are
  88 incomplete because the last/smallest mipmap level (1 x 1 pixel) is
  89 never specified.
  90 </p>
  91
  92 <p>
  93 A trace captured with
  94 <a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
  95 shows this sequences of calls like this:
  96
  97 <pre>
  98 2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
  99 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))
 100 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))
 101 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))
 102 [...]
 103 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))
 104 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))
 105 2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
 106 2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
 107 2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
 108 2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
 109 </pre>
 110
 111 <p>
 112 Note that one would expect call 2514 to be glTexImage(level=9, width=1,
 113 height=1) but it's not there.
 114 </p>
 115
 116 <p>
 117 The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
 118 GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
 119 </p>
 120
 121 <p>
 122 Later, these incomplete textures are bound before drawing calls.
 123 According to the GL specification, if a fragment program or fragment shader
 124 is being used, the sampler should return (0,0,0,1) ("black") when sampling
 125 from an incomplete texture.
 126 This is what Mesa does and the resulting rendering is darker than it should
 127 be.
 128 </p>
 129
 130 <p>
 131 It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
 132 and returns (1,1,1,1) (white) which causes the rendering to appear brighter
 133 and match the reference image (however, AMD's rendering is <em>much</em>
 134 brighter than NVIDIA's).
 135 </p>
 136
 137 <p>
 138 If the fallback texture created in _mesa_get_fallback_texture() is
 139 initialized to be full white instead of full black the rendering appears
 140 correct.
 141 However, we have no plans to implement this work-around in Mesa.
 142
 143 </p>
 144
 145
 146 </BODY>
 147 </HTML>