viewperf.html revision 0615eb8fc3e516f56c27cddb6206f4e53142506c
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 88 89<h2>sw-02 test 6</h2> 90 91<p> 92The lines drawn in this test appear in a random color. 93That's because texture mapping is enabled when the lines are drawn, but no 94texture image is defined (glTexImage2D() is called with pixels=NULL). 95Since GL says the contents of the texture image are undefined in that 96situation, we get a random color. 97</p> 98 99 100 101<h2>Lightwave-01 test 3</h2> 102 103<p> 104This test uses a number of mipmapped textures, but the textures are 105incomplete because the last/smallest mipmap level (1 x 1 pixel) is 106never specified. 107</p> 108 109<p> 110A trace captured with 111<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a> 112shows this sequences of calls like this: 113 114<pre> 1152504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) 1162505 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)) 1172506 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)) 1182507 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)) 119[...] 1202512 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)) 1212513 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)) 1222514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) 1232515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) 1242516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) 1252517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 126</pre> 127 128<p> 129Note that one would expect call 2514 to be glTexImage(level=9, width=1, 130height=1) but it's not there. 131</p> 132 133<p> 134The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's 135GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. 136</p> 137 138<p> 139Later, these incomplete textures are bound before drawing calls. 140According to the GL specification, if a fragment program or fragment shader 141is being used, the sampler should return (0,0,0,1) ("black") when sampling 142from an incomplete texture. 143This is what Mesa does and the resulting rendering is darker than it should 144be. 145</p> 146 147<p> 148It appears that NVIDIA's driver (and possibly AMD's driver) detects this case 149and returns (1,1,1,1) (white) which causes the rendering to appear brighter 150and match the reference image (however, AMD's rendering is <em>much</em> 151brighter than NVIDIA's). 152</p> 153 154<p> 155If the fallback texture created in _mesa_get_fallback_texture() is 156initialized to be full white instead of full black the rendering appears 157correct. 158However, we have no plans to implement this work-around in Mesa. 159</p> 160 161 162<h2>Maya-03 test 2</h2> 163 164<p> 165This test makes some unusual calls to glRotate. For example: 166</p> 167<pre> 168glRotate(50, 50, 50, 1); 169glRotate(100, 100, 100, 1); 170glRotate(52, 52, 52, 1); 171</pre> 172<p> 173These unusual values lead to invalid modelview matrices. 174For example, the last glRotate command above produces this matrix with Mesa: 175<pre> 1761.08536e+24 2.55321e-23 -0.000160389 0 1775.96937e-25 1.08536e+24 103408 0 178103408 -0.000160389 1.74755e+09 0 1790 0 0 nan 180</pre> 181and with NVIDIA's OpenGL: 182<pre> 1831.4013e-45 0 -nan 0 1840 1.4013e-45 1.4013e-45 0 1851.4013e-45 -nan 1.4013e-45 0 1860 0 0 1.4013e-45 187</pre> 188<p> 189This causes the object in question to be drawn in a strange orientation 190and with a semi-random color (between white and black) since GL_FOG is enabled. 191</p> 192 193 194</BODY> 195</HTML> 196