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