viewperf.html revision a0c380a7442a932edce03e0ddcf98af9d3e76f51
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<p> 36Some of the Viewperf tests use a lot of memory. 37At least 2GB of RAM is recommended. 38</p> 39 40 41<h2>Catia-03 test 2</h2> 42 43<p> 44This test creates over 38000 vertex buffer objects. On some systems 45this can exceed the maximum number of buffer allocations. Mesa 46generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf 47does no error checking and continues. When this happens, some drawing 48commands become no-ops. This can also eventually lead to a segfault 49either in Viewperf or the Mesa driver. 50</p> 51 52 53 54<h2>Catia-03 tests 3, 4, 8</h2> 55 56<p> 57These tests use features of the 58<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt" 59target="_main"> 60GL_NV_fragment_program2</a> and 61<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt" 62target="_main"> 63GL_NV_vertex_program3</a> extensions without checking if the driver supports 64them. 65</p> 66<p> 67When Mesa tries to compile the vertex/fragment programs it generates errors 68(which Viewperf ignores). 69Subsequent 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> 77These tests depend on the 78<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt" 79target="_main">GL_NV_primitive_restart</a> extension. 80</p> 81 82<p> 83If the Mesa driver doesn't support this extension the rendering will 84be incorrect and the test will fail. 85</p> 86 87<p> 88Also, the color of the line drawings in test 2 seem to appear in a random 89color. This is probably due to some uninitialized state somewhere. 90</p> 91 92 93 94<h2>sw-02 test 6</h2> 95 96<p> 97The lines drawn in this test appear in a random color. 98That's because texture mapping is enabled when the lines are drawn, but no 99texture image is defined (glTexImage2D() is called with pixels=NULL). 100Since GL says the contents of the texture image are undefined in that 101situation, we get a random color. 102</p> 103 104 105 106<h2>Lightwave-01 test 3</h2> 107 108<p> 109This test uses a number of mipmapped textures, but the textures are 110incomplete because the last/smallest mipmap level (1 x 1 pixel) is 111never specified. 112</p> 113 114<p> 115A trace captured with 116<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a> 117shows this sequences of calls like this: 118 119<pre> 1202504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) 1212505 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)) 1222506 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)) 1232507 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[...] 1252512 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)) 1262513 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)) 1272514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) 1282515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) 1292516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) 1302517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 131</pre> 132 133<p> 134Note that one would expect call 2514 to be glTexImage(level=9, width=1, 135height=1) but it's not there. 136</p> 137 138<p> 139The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's 140GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. 141</p> 142 143<p> 144Later, these incomplete textures are bound before drawing calls. 145According to the GL specification, if a fragment program or fragment shader 146is being used, the sampler should return (0,0,0,1) ("black") when sampling 147from an incomplete texture. 148This is what Mesa does and the resulting rendering is darker than it should 149be. 150</p> 151 152<p> 153It appears that NVIDIA's driver (and possibly AMD's driver) detects this case 154and returns (1,1,1,1) (white) which causes the rendering to appear brighter 155and match the reference image (however, AMD's rendering is <em>much</em> 156brighter than NVIDIA's). 157</p> 158 159<p> 160If the fallback texture created in _mesa_get_fallback_texture() is 161initialized to be full white instead of full black the rendering appears 162correct. 163However, 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> 170This test makes some unusual calls to glRotate. For example: 171</p> 172<pre> 173glRotate(50, 50, 50, 1); 174glRotate(100, 100, 100, 1); 175glRotate(52, 52, 52, 1); 176</pre> 177<p> 178These unusual values lead to invalid modelview matrices. 179For example, the last glRotate command above produces this matrix with Mesa: 180<pre> 1811.08536e+24 2.55321e-23 -0.000160389 0 1825.96937e-25 1.08536e+24 103408 0 183103408 -0.000160389 1.74755e+09 0 1840 0 0 nan 185</pre> 186and with NVIDIA's OpenGL: 187<pre> 1881.4013e-45 0 -nan 0 1890 1.4013e-45 1.4013e-45 0 1901.4013e-45 -nan 1.4013e-45 0 1910 0 0 1.4013e-45 192</pre> 193<p> 194This causes the object in question to be drawn in a strange orientation 195and with a semi-random color (between white and black) since GL_FOG is enabled. 196</p> 197 198 199</BODY> 200</HTML> 201