viewperf.html revision 848b8605
1848b8605Smrg<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2848b8605Smrg<html lang="en"> 3848b8605Smrg<head> 4848b8605Smrg <meta http-equiv="content-type" content="text/html; charset=utf-8"> 5848b8605Smrg <title>Viewperf Issues</title> 6848b8605Smrg <link rel="stylesheet" type="text/css" href="mesa.css"> 7848b8605Smrg</head> 8848b8605Smrg<body> 9848b8605Smrg 10848b8605Smrg<div class="header"> 11848b8605Smrg <h1>The Mesa 3D Graphics Library</h1> 12848b8605Smrg</div> 13848b8605Smrg 14848b8605Smrg<iframe src="contents.html"></iframe> 15848b8605Smrg<div class="content"> 16848b8605Smrg 17848b8605Smrg<h1>Viewperf Issues</h1> 18848b8605Smrg 19848b8605Smrg<p> 20848b8605SmrgThis page lists known issues with 21848b8605Smrg<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a> 22848b8605Smrgwhen running on Mesa-based drivers. 23848b8605Smrg</p> 24848b8605Smrg 25848b8605Smrg<p> 26848b8605SmrgThe Viewperf data sets are basically GL API traces that are recorded from 27848b8605SmrgCAD applications, then replayed in the Viewperf framework. 28848b8605Smrg</p> 29848b8605Smrg 30848b8605Smrg<p> 31848b8605SmrgThe primary problem with these traces is they blindly use features and 32848b8605SmrgOpenGL extensions that were supported by the OpenGL driver when the trace 33848b8605Smrgwas recorded, 34848b8605Smrgbut there's no checks to see if those features are supported by the driver 35848b8605Smrgwhen playing back the traces with Viewperf. 36848b8605Smrg</p> 37848b8605Smrg 38848b8605Smrg<p> 39848b8605SmrgThese issues have been reported to the SPEC organization in the hope that 40848b8605Smrgthey'll be fixed in the future. 41848b8605Smrg</p> 42848b8605Smrg 43848b8605Smrg<p> 44848b8605SmrgSome of the Viewperf tests use a lot of memory. 45848b8605SmrgAt least 2GB of RAM is recommended. 46848b8605Smrg</p> 47848b8605Smrg 48848b8605Smrg 49848b8605Smrg<h2>Catia-03 test 2</h2> 50848b8605Smrg 51848b8605Smrg<p> 52848b8605SmrgThis test creates over 38000 vertex buffer objects. On some systems 53848b8605Smrgthis can exceed the maximum number of buffer allocations. Mesa 54848b8605Smrggenerates GL_OUT_OF_MEMORY errors in this situation, but Viewperf 55848b8605Smrgdoes no error checking and continues. When this happens, some drawing 56848b8605Smrgcommands become no-ops. This can also eventually lead to a segfault 57848b8605Smrgeither in Viewperf or the Mesa driver. 58848b8605Smrg</p> 59848b8605Smrg 60848b8605Smrg 61848b8605Smrg 62848b8605Smrg<h2>Catia-03 tests 3, 4, 8</h2> 63848b8605Smrg 64848b8605Smrg<p> 65848b8605SmrgThese tests use features of the 66848b8605Smrg<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt" 67848b8605Smrgtarget="_main"> 68848b8605SmrgGL_NV_fragment_program2</a> and 69848b8605Smrg<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt" 70848b8605Smrgtarget="_main"> 71848b8605SmrgGL_NV_vertex_program3</a> extensions without checking if the driver supports 72848b8605Smrgthem. 73848b8605Smrg</p> 74848b8605Smrg<p> 75848b8605SmrgWhen Mesa tries to compile the vertex/fragment programs it generates errors 76848b8605Smrg(which Viewperf ignores). 77848b8605SmrgSubsequent drawing calls become no-ops and the rendering is incorrect. 78848b8605Smrg</p> 79848b8605Smrg 80848b8605Smrg 81848b8605Smrg 82848b8605Smrg<h2>sw-02 tests 1, 2, 4, 6</h2> 83848b8605Smrg 84848b8605Smrg<p> 85848b8605SmrgThese tests depend on the 86848b8605Smrg<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt" 87848b8605Smrgtarget="_main">GL_NV_primitive_restart</a> extension. 88848b8605Smrg</p> 89848b8605Smrg 90848b8605Smrg<p> 91848b8605SmrgIf the Mesa driver doesn't support this extension the rendering will 92848b8605Smrgbe incorrect and the test will fail. 93848b8605Smrg</p> 94848b8605Smrg 95848b8605Smrg<p> 96848b8605SmrgAlso, the color of the line drawings in test 2 seem to appear in a random 97848b8605Smrgcolor. This is probably due to some uninitialized state somewhere. 98848b8605Smrg</p> 99848b8605Smrg 100848b8605Smrg 101848b8605Smrg 102848b8605Smrg<h2>sw-02 test 6</h2> 103848b8605Smrg 104848b8605Smrg<p> 105848b8605SmrgThe lines drawn in this test appear in a random color. 106848b8605SmrgThat's because texture mapping is enabled when the lines are drawn, but no 107848b8605Smrgtexture image is defined (glTexImage2D() is called with pixels=NULL). 108848b8605SmrgSince GL says the contents of the texture image are undefined in that 109848b8605Smrgsituation, we get a random color. 110848b8605Smrg</p> 111848b8605Smrg 112848b8605Smrg 113848b8605Smrg 114848b8605Smrg<h2>Lightwave-01 test 3</h2> 115848b8605Smrg 116848b8605Smrg<p> 117848b8605SmrgThis test uses a number of mipmapped textures, but the textures are 118848b8605Smrgincomplete because the last/smallest mipmap level (1 x 1 pixel) is 119848b8605Smrgnever specified. 120848b8605Smrg</p> 121848b8605Smrg 122848b8605Smrg<p> 123848b8605SmrgA trace captured with 124848b8605Smrg<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a> 125848b8605Smrgshows this sequences of calls like this: 126848b8605Smrg 127848b8605Smrg<pre> 128848b8605Smrg2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) 129848b8605Smrg2505 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)) 130848b8605Smrg2506 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)) 131848b8605Smrg2507 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)) 132848b8605Smrg[...] 133848b8605Smrg2512 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)) 134848b8605Smrg2513 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)) 135848b8605Smrg2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) 136848b8605Smrg2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) 137848b8605Smrg2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) 138848b8605Smrg2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 139848b8605Smrg</pre> 140848b8605Smrg 141848b8605Smrg<p> 142848b8605SmrgNote that one would expect call 2514 to be glTexImage(level=9, width=1, 143848b8605Smrgheight=1) but it's not there. 144848b8605Smrg</p> 145848b8605Smrg 146848b8605Smrg<p> 147848b8605SmrgThe minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's 148848b8605SmrgGL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. 149848b8605Smrg</p> 150848b8605Smrg 151848b8605Smrg<p> 152848b8605SmrgLater, these incomplete textures are bound before drawing calls. 153848b8605SmrgAccording to the GL specification, if a fragment program or fragment shader 154848b8605Smrgis being used, the sampler should return (0,0,0,1) ("black") when sampling 155848b8605Smrgfrom an incomplete texture. 156848b8605SmrgThis is what Mesa does and the resulting rendering is darker than it should 157848b8605Smrgbe. 158848b8605Smrg</p> 159848b8605Smrg 160848b8605Smrg<p> 161848b8605SmrgIt appears that NVIDIA's driver (and possibly AMD's driver) detects this case 162848b8605Smrgand returns (1,1,1,1) (white) which causes the rendering to appear brighter 163848b8605Smrgand match the reference image (however, AMD's rendering is <em>much</em> 164848b8605Smrgbrighter than NVIDIA's). 165848b8605Smrg</p> 166848b8605Smrg 167848b8605Smrg<p> 168848b8605SmrgIf the fallback texture created in _mesa_get_fallback_texture() is 169848b8605Smrginitialized to be full white instead of full black the rendering appears 170848b8605Smrgcorrect. 171848b8605SmrgHowever, we have no plans to implement this work-around in Mesa. 172848b8605Smrg</p> 173848b8605Smrg 174848b8605Smrg 175848b8605Smrg<h2>Maya-03 test 2</h2> 176848b8605Smrg 177848b8605Smrg<p> 178848b8605SmrgThis test makes some unusual calls to glRotate. For example: 179848b8605Smrg</p> 180848b8605Smrg<pre> 181848b8605SmrgglRotate(50, 50, 50, 1); 182848b8605SmrgglRotate(100, 100, 100, 1); 183848b8605SmrgglRotate(52, 52, 52, 1); 184848b8605Smrg</pre> 185848b8605Smrg<p> 186848b8605SmrgThese unusual values lead to invalid modelview matrices. 187848b8605SmrgFor example, the last glRotate command above produces this matrix with Mesa: 188848b8605Smrg<pre> 189848b8605Smrg1.08536e+24 2.55321e-23 -0.000160389 0 190848b8605Smrg5.96937e-25 1.08536e+24 103408 0 191848b8605Smrg103408 -0.000160389 1.74755e+09 0 192848b8605Smrg0 0 0 nan 193848b8605Smrg</pre> 194848b8605Smrgand with NVIDIA's OpenGL: 195848b8605Smrg<pre> 196848b8605Smrg1.4013e-45 0 -nan 0 197848b8605Smrg0 1.4013e-45 1.4013e-45 0 198848b8605Smrg1.4013e-45 -nan 1.4013e-45 0 199848b8605Smrg0 0 0 1.4013e-45 200848b8605Smrg</pre> 201848b8605Smrg<p> 202848b8605SmrgThis causes the object in question to be drawn in a strange orientation 203848b8605Smrgand with a semi-random color (between white and black) since GL_FOG is enabled. 204848b8605Smrg</p> 205848b8605Smrg 206848b8605Smrg 207848b8605Smrg<h2>Proe-05 test 1</h2> 208848b8605Smrg 209848b8605Smrg<p> 210848b8605SmrgThis uses depth testing but there's two problems: 211848b8605Smrg<ol> 212848b8605Smrg<li>The glXChooseFBConfig() call doesn't request a depth buffer 213848b8605Smrg<li>The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer 214848b8605Smrg</ol> 215848b8605Smrg<p> 216848b8605SmrgIf the chosen visual does not have a depth buffer, you'll see the wireframe 217848b8605Smrgcar model but it won't be rendered correctly. 218848b8605Smrg</p> 219848b8605SmrgIf (by luck) the chosen visual has a depth buffer, its initial contents 220848b8605Smrgwill be undefined so you may or may not see parts of the model. 221848b8605Smrg<p> 222848b8605SmrgInterestingly, with NVIDIA's driver most visuals happen to have a depth buffer 223848b8605Smrgand apparently the contents are initialized to 1.0 by default so this test 224848b8605Smrgjust happens to work with their drivers. 225848b8605Smrg</p> 226848b8605Smrg 227848b8605Smrg<p> 228848b8605SmrgFinally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT) 229848b8605Smrgcalls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) 230848b8605Smrgthe problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when 231848b8605SmrgglClear is called so clearing the depth buffer would be a no-op anyway. 232848b8605Smrg</p> 233848b8605Smrg 234848b8605Smrg 235848b8605Smrg<h2>Proe-05 test 6</h2> 236848b8605Smrg 237848b8605Smrg<p> 238848b8605SmrgThis test draws an engine model with a two-pass algorithm. 239848b8605SmrgThe first pass is drawn with polygon stipple enabled. 240848b8605SmrgThe second pass is drawn without polygon stipple but with blending 241848b8605Smrgand GL_DEPTH_FUNC=GL_LEQUAL. 242848b8605SmrgIf either of the two passes happen to use a software fallback of some 243848b8605Smrgsort, the Z values of fragments may be different between the two passes. 244848b8605SmrgThis leads to incorrect rendering. 245848b8605Smrg</p> 246848b8605Smrg 247848b8605Smrg<p> 248848b8605SmrgFor example, the VMware SVGA gallium driver uses a special semi-fallback path 249848b8605Smrgfor drawing with polygon stipple. 250848b8605SmrgSince the two passes are rendered with different vertex transformation 251848b8605Smrgimplementations, the rendering doesn't appear as expected. 252848b8605SmrgSetting the SVGA_FORCE_SWTNL environment variable to 1 will force the 253848b8605Smrgdriver to use the software vertex path all the time and clears up this issue. 254848b8605Smrg</p> 255848b8605Smrg 256848b8605Smrg<p> 257848b8605SmrgAccording to the OpenGL invariance rules, there's no guarantee that 258848b8605Smrgthe pixels produced by these two rendering states will match. 259848b8605SmrgTo achieve invariance, both passes should enable polygon stipple and 260848b8605Smrgblending with appropriate patterns/modes to ensure the same fragments 261848b8605Smrgare produced in both passes. 262848b8605Smrg</p> 263848b8605Smrg 264848b8605Smrg 265848b8605Smrg</div> 266848b8605Smrg</body> 267848b8605Smrg</html> 268