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