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