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 21b8e80941Smrg<a href="https://www.spec.org/gwpg/gpc.static/vp11info.html">SPEC Viewperf 11</a> 22b8e80941Smrgand <a href="https://www.spec.org/gwpg/gpc.static/vp12info.html">SPEC Viewperf 12</a> 23848b8605Smrgwhen running on Mesa-based drivers. 24848b8605Smrg</p> 25848b8605Smrg 26848b8605Smrg<p> 27848b8605SmrgThe Viewperf data sets are basically GL API traces that are recorded from 28848b8605SmrgCAD applications, then replayed in the Viewperf framework. 29848b8605Smrg</p> 30848b8605Smrg 31848b8605Smrg<p> 32848b8605SmrgThe primary problem with these traces is they blindly use features and 33848b8605SmrgOpenGL extensions that were supported by the OpenGL driver when the trace 34848b8605Smrgwas recorded, 35848b8605Smrgbut there's no checks to see if those features are supported by the driver 36848b8605Smrgwhen playing back the traces with Viewperf. 37848b8605Smrg</p> 38848b8605Smrg 39848b8605Smrg<p> 40848b8605SmrgThese issues have been reported to the SPEC organization in the hope that 41848b8605Smrgthey'll be fixed in the future. 42848b8605Smrg</p> 43848b8605Smrg 44b8e80941Smrg<h2><u>Viewperf 11</u></h2> 45b8e80941Smrg 46848b8605Smrg<p> 47b8e80941SmrgSome of the Viewperf 11 tests use a lot of memory. 48848b8605SmrgAt least 2GB of RAM is recommended. 49848b8605Smrg</p> 50848b8605Smrg 51848b8605Smrg 52b8e80941Smrg<h3>Catia-03 test 2</h3> 53848b8605Smrg 54848b8605Smrg<p> 55848b8605SmrgThis test creates over 38000 vertex buffer objects. On some systems 56848b8605Smrgthis can exceed the maximum number of buffer allocations. Mesa 57848b8605Smrggenerates GL_OUT_OF_MEMORY errors in this situation, but Viewperf 58848b8605Smrgdoes no error checking and continues. When this happens, some drawing 59848b8605Smrgcommands become no-ops. This can also eventually lead to a segfault 60848b8605Smrgeither in Viewperf or the Mesa driver. 61848b8605Smrg</p> 62848b8605Smrg 63848b8605Smrg 64848b8605Smrg 65b8e80941Smrg<h3>Catia-03 tests 3, 4, 8</h3> 66848b8605Smrg 67848b8605Smrg<p> 68848b8605SmrgThese tests use features of the 69b8e80941Smrg<a href="https://www.opengl.org/registry/specs/NV/fragment_program2.txt">GL_NV_fragment_program2</a> 70b8e80941Smrgand 71b8e80941Smrg<a href="https://www.opengl.org/registry/specs/NV/vertex_program3.txt">GL_NV_vertex_program3</a> 72b8e80941Smrgextensions without checking if the driver supports them. 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 82b8e80941Smrg<h3>sw-02 tests 1, 2, 4, 6</h3> 83848b8605Smrg 84848b8605Smrg<p> 85848b8605SmrgThese tests depend on the 86b8e80941Smrg<a href="https://www.opengl.org/registry/specs/NV/primitive_restart.txt">GL_NV_primitive_restart</a> 87b8e80941Smrgextension. 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 102b8e80941Smrg<h3>sw-02 test 6</h3> 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 114b8e80941Smrg<h3>Lightwave-01 test 3</h3> 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 124b8e80941Smrg<a href="https://github.com/apitrace/apitrace">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 175b8e80941Smrg<h3>Maya-03 test 2</h3> 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 207b8e80941Smrg<h3>Proe-05 test 1</h3> 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 235b8e80941Smrg<h3>Proe-05 test 6</h3> 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 264b8e80941Smrg<h2><u>Viewperf 12</u></h2> 265b8e80941Smrg 266b8e80941Smrg<p> 267b8e80941SmrgNote that Viewperf 12 only runs on 64-bit Windows 7 or later. 268b8e80941Smrg</p> 269b8e80941Smrg 270b8e80941Smrg<h3>catia-04</h3> 271b8e80941Smrg 272b8e80941Smrg<p> 273b8e80941SmrgOne of the catia tests calls wglGetProcAddress() to get some 274b8e80941SmrgGL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and some 275b8e80941SmrgGL_NV_half_float functions (such as glMultiTexCoord3hNV). 276b8e80941SmrgIf the extension/function is not supported, wglGetProcAddress() can return NULL. 277b8e80941SmrgUnfortunately, Viewperf doesn't check for null pointers and crashes when it 278b8e80941Smrglater tries to use the pointer. 279b8e80941Smrg</p> 280b8e80941Smrg 281b8e80941Smrg<p> 282b8e80941SmrgAnother catia test uses OpenGL 3.1's primitive restart feature. 283b8e80941SmrgBut when Viewperf creates an OpenGL context, it doesn't request version 3.1 284b8e80941SmrgIf the driver returns version 3.0 or earlier all the calls related to primitive 285b8e80941Smrgrestart generate an OpenGL error. 286b8e80941SmrgSome of the rendering is then incorrect. 287b8e80941Smrg</p> 288b8e80941Smrg 289b8e80941Smrg 290b8e80941Smrg<h3>energy-01</h3> 291b8e80941Smrg 292b8e80941Smrg<p> 293b8e80941SmrgThis test creates a 3D luminance texture of size 1K x 1K x 1K. 294b8e80941SmrgIf the OpenGL driver/device doesn't support a texture of this size 295b8e80941Smrgthe glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY 296b8e80941Smrgand all that's rendered is plain white polygons. 297b8e80941SmrgIdeally, the test would use a proxy texture to determine the max 3D 298b8e80941Smrgtexture size. But it does not do that. 299b8e80941Smrg</p> 300b8e80941Smrg 301b8e80941Smrg<h3>maya-04</h3> 302b8e80941Smrg 303b8e80941Smrg<p> 304b8e80941SmrgThis test generates many GL_INVALID_OPERATION errors in its calls to 305b8e80941SmrgglUniform(). 306b8e80941SmrgCauses include: 307b8e80941Smrg<ul> 308b8e80941Smrg<li> Trying to set float uniforms with glUniformi() 309b8e80941Smrg<li> Trying to set float uniforms with glUniform3f() 310b8e80941Smrg<li> Trying to set matrix uniforms with glUniform() instead of glUniformMatrix(). 311b8e80941Smrg</ul> 312b8e80941Smrg<p> 313b8e80941SmrgApparently, the indexes returned by glGetUniformLocation() were hard-coded 314b8e80941Smrginto the application trace when it was created. 315b8e80941SmrgSince different implementations of glGetUniformLocation() may return different 316b8e80941Smrgvalues for any given uniform name, subsequent calls to glUniform() will be 317b8e80941Smrginvalid since they refer to the wrong uniform variables. 318b8e80941SmrgThis causes many OpenGL errors and leads to incorrect rendering. 319b8e80941Smrg</p> 320b8e80941Smrg 321b8e80941Smrg<h3>medical-01</h3> 322b8e80941Smrg 323b8e80941Smrg<p> 324b8e80941SmrgThis test uses a single GLSL fragment shader which contains a GLSL 1.20 325b8e80941Smrgarray initializer statement, but it neglects to specify 326b8e80941Smrg<code>#version 120</code> at the top of the shader code. 327b8e80941SmrgSo, the shader does not compile and all that's rendered is plain white polygons. 328b8e80941Smrg</p> 329b8e80941Smrg<p> 330b8e80941SmrgAlso, the test tries to create a very large 3D texture that may exceed 331b8e80941Smrgthe device driver's limit. 332b8e80941SmrgWhen this happens, the glTexImage3D call fails and all that's rendered is 333b8e80941Smrga white box. 334b8e80941Smrg</p> 335b8e80941Smrg 336b8e80941Smrg 337b8e80941Smrg<h3>showcase-01</h3> 338b8e80941Smrg 339b8e80941Smrg<p> 340b8e80941SmrgThis is actually a DX11 test based on Autodesk's Showcase product. 341b8e80941SmrgAs such, it won't run with Mesa. 342b8e80941Smrg</p> 343b8e80941Smrg 344848b8605Smrg 345848b8605Smrg</div> 346848b8605Smrg</body> 347848b8605Smrg</html> 348