Blame - docs/viewperf.html - platform/external/mesa3d

blob: ed89ee2cfeaf7cb63399c1db0318940c909187ec [file] [log] [blame]

Andreas Boll	ecd5c7c	2012-06-12 09:05:03 +0200	[diff] [blame]	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
				2	<html lang="en">
				3	<head>
				4	<meta http-equiv="content-type" content="text/html; charset=utf-8">
				5	<title>Viewperf Issues</title>
				6	<link rel="stylesheet" type="text/css" href="mesa.css">
				7	</head>
				8	<body>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	9
Andreas Boll	b5da52a	2012-09-18 18:57:02 +0200	[diff] [blame]	10	<div class="header">
				11	<h1>The Mesa 3D Graphics Library</h1>
				12	</div>
				13
				14	<iframe src="contents.html"></iframe>
				15	<div class="content">
				16
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	17	<h1>Viewperf Issues</h1>
				18
				19	<p>
				20	This page lists known issues with
Eric Engestrom	ec98624	2018-05-23 12:47:33 +0100	[diff] [blame]	21	<a href="https://www.spec.org/gwpg/gpc.static/vp11info.html">SPEC Viewperf 11</a>
				22	and <a href="https://www.spec.org/gwpg/gpc.static/vp12info.html">SPEC Viewperf 12</a>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	23	when running on Mesa-based drivers.
				24	</p>
				25
				26	<p>
				27	The Viewperf data sets are basically GL API traces that are recorded from
				28	CAD applications, then replayed in the Viewperf framework.
				29	</p>
				30
				31	<p>
				32	The primary problem with these traces is they blindly use features and
				33	OpenGL extensions that were supported by the OpenGL driver when the trace
				34	was recorded,
				35	but there's no checks to see if those features are supported by the driver
				36	when playing back the traces with Viewperf.
				37	</p>
				38
				39	<p>
				40	These issues have been reported to the SPEC organization in the hope that
				41	they'll be fixed in the future.
				42	</p>
				43
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	44	<h2><u>Viewperf 11</u></h2>
				45
Brian Paul	0615eb8	2012-04-19 14:38:45 -0600	[diff] [blame]	46	<p>
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	47	Some of the Viewperf 11 tests use a lot of memory.
Brian Paul	0615eb8	2012-04-19 14:38:45 -0600	[diff] [blame]	48	At least 2GB of RAM is recommended.
				49	</p>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	50
				51
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	52	<h3>Catia-03 test 2</h3>
Brian Paul	9c0d782	2011-11-09 13:32:18 -0700	[diff] [blame]	53
				54	<p>
				55	This test creates over 38000 vertex buffer objects. On some systems
				56	this can exceed the maximum number of buffer allocations. Mesa
				57	generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
				58	does no error checking and continues. When this happens, some drawing
				59	commands become no-ops. This can also eventually lead to a segfault
				60	either in Viewperf or the Mesa driver.
				61	</p>
				62
				63
				64
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	65	<h3>Catia-03 tests 3, 4, 8</h3>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	66
				67	<p>
				68	These tests use features of the
Eric Engestrom	ec98624	2018-05-23 12:47:33 +0100	[diff] [blame]	69	<a href="https://www.opengl.org/registry/specs/NV/fragment_program2.txt">GL_NV_fragment_program2</a>
				70	and
				71	<a href="https://www.opengl.org/registry/specs/NV/vertex_program3.txt">GL_NV_vertex_program3</a>
				72	extensions without checking if the driver supports them.
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	73	</p>
				74	<p>
				75	When Mesa tries to compile the vertex/fragment programs it generates errors
				76	(which Viewperf ignores).
				77	Subsequent drawing calls become no-ops and the rendering is incorrect.
				78	</p>
				79
				80
				81
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	82	<h3>sw-02 tests 1, 2, 4, 6</h3>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	83
				84	<p>
				85	These tests depend on the
Eric Engestrom	ec98624	2018-05-23 12:47:33 +0100	[diff] [blame]	86	<a href="https://www.opengl.org/registry/specs/NV/primitive_restart.txt">GL_NV_primitive_restart</a>
				87	extension.
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	88	</p>
				89
				90	<p>
				91	If the Mesa driver doesn't support this extension the rendering will
				92	be incorrect and the test will fail.
				93	</p>
				94
Brian Paul	a0c380a	2012-05-01 15:49:31 -0600	[diff] [blame]	95	<p>
				96	Also, the color of the line drawings in test 2 seem to appear in a random
				97	color. This is probably due to some uninitialized state somewhere.
				98	</p>
				99
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	100
Brian Paul	0fd4165	2012-04-11 11:53:33 -0600	[diff] [blame]	101
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	102	<h3>sw-02 test 6</h3>
Brian Paul	0fd4165	2012-04-11 11:53:33 -0600	[diff] [blame]	103
				104	<p>
				105	The lines drawn in this test appear in a random color.
				106	That's because texture mapping is enabled when the lines are drawn, but no
				107	texture image is defined (glTexImage2D() is called with pixels=NULL).
				108	Since GL says the contents of the texture image are undefined in that
				109	situation, we get a random color.
				110	</p>
				111
				112
				113
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	114	<h3>Lightwave-01 test 3</h3>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	115
				116	<p>
				117	This test uses a number of mipmapped textures, but the textures are
				118	incomplete because the last/smallest mipmap level (1 x 1 pixel) is
				119	never specified.
				120	</p>
				121
				122	<p>
				123	A trace captured with
Eric Engestrom	ec98624	2018-05-23 12:47:33 +0100	[diff] [blame]	124	<a href="https://github.com/apitrace/apitrace">API trace</a>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	125	shows this sequences of calls like this:
				126
				127	<pre>
				128	2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
				129	2505 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))
				130	2506 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))
				131	2507 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))
				132	[...]
				133	2512 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))
				134	2513 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))
				135	2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
				136	2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
				137	2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
				138	2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
				139	</pre>
				140
				141	<p>
				142	Note that one would expect call 2514 to be glTexImage(level=9, width=1,
				143	height=1) but it's not there.
				144	</p>
				145
				146	<p>
				147	The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
				148	GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
				149	</p>
				150
				151	<p>
				152	Later, these incomplete textures are bound before drawing calls.
				153	According to the GL specification, if a fragment program or fragment shader
				154	is being used, the sampler should return (0,0,0,1) ("black") when sampling
				155	from an incomplete texture.
				156	This is what Mesa does and the resulting rendering is darker than it should
				157	be.
				158	</p>
				159
				160	<p>
				161	It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
				162	and returns (1,1,1,1) (white) which causes the rendering to appear brighter
				163	and match the reference image (however, AMD's rendering is <em>much</em>
				164	brighter than NVIDIA's).
				165	</p>
				166
				167	<p>
				168	If the fallback texture created in _mesa_get_fallback_texture() is
				169	initialized to be full white instead of full black the rendering appears
				170	correct.
				171	However, we have no plans to implement this work-around in Mesa.
Brian Paul	286e50a	2012-04-13 14:31:16 -0600	[diff] [blame]	172	</p>
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	173
Brian Paul	286e50a	2012-04-13 14:31:16 -0600	[diff] [blame]	174
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	175	<h3>Maya-03 test 2</h3>
Brian Paul	286e50a	2012-04-13 14:31:16 -0600	[diff] [blame]	176
				177	<p>
				178	This test makes some unusual calls to glRotate. For example:
				179	</p>
				180	<pre>
				181	glRotate(50, 50, 50, 1);
				182	glRotate(100, 100, 100, 1);
				183	glRotate(52, 52, 52, 1);
				184	</pre>
				185	<p>
				186	These unusual values lead to invalid modelview matrices.
				187	For example, the last glRotate command above produces this matrix with Mesa:
				188	<pre>
				189	1.08536e+24 2.55321e-23 -0.000160389 0
				190	5.96937e-25 1.08536e+24 103408 0
				191	103408 -0.000160389 1.74755e+09 0
				192	0 0 0 nan
				193	</pre>
				194	and with NVIDIA's OpenGL:
				195	<pre>
				196	1.4013e-45 0 -nan 0
				197	0 1.4013e-45 1.4013e-45 0
				198	1.4013e-45 -nan 1.4013e-45 0
				199	0 0 0 1.4013e-45
				200	</pre>
				201	<p>
				202	This causes the object in question to be drawn in a strange orientation
				203	and with a semi-random color (between white and black) since GL_FOG is enabled.
Brian Paul	c60eb63	2011-10-20 15:13:17 -0600	[diff] [blame]	204	</p>
				205
Brian Paul	728240b	2013-03-08 10:32:39 -0700	[diff] [blame]	206
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	207	<h3>Proe-05 test 1</h3>
Brian Paul	728240b	2013-03-08 10:32:39 -0700	[diff] [blame]	208
				209	<p>
				210	This uses depth testing but there's two problems:
				211	<ol>
				212	<li>The glXChooseFBConfig() call doesn't request a depth buffer
				213	<li>The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer
				214	</ol>
				215	<p>
				216	If the chosen visual does not have a depth buffer, you'll see the wireframe
				217	car model but it won't be rendered correctly.
				218	</p>
				219	If (by luck) the chosen visual has a depth buffer, its initial contents
				220	will be undefined so you may or may not see parts of the model.
				221	<p>
				222	Interestingly, with NVIDIA's driver most visuals happen to have a depth buffer
				223	and apparently the contents are initialized to 1.0 by default so this test
				224	just happens to work with their drivers.
				225	</p>
				226
				227	<p>
				228	Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT)
				229	calls were changed to glClear(GL_COLOR_BUFFER_BIT \| GL_DEPTH_BUFFER_BIT)
				230	the problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when
				231	glClear is called so clearing the depth buffer would be a no-op anyway.
				232	</p>
				233
				234
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	235	<h3>Proe-05 test 6</h3>
Brian Paul	71ee003	2013-04-23 13:18:41 -0600	[diff] [blame]	236
				237	<p>
				238	This test draws an engine model with a two-pass algorithm.
				239	The first pass is drawn with polygon stipple enabled.
				240	The second pass is drawn without polygon stipple but with blending
				241	and GL_DEPTH_FUNC=GL_LEQUAL.
				242	If either of the two passes happen to use a software fallback of some
				243	sort, the Z values of fragments may be different between the two passes.
				244	This leads to incorrect rendering.
				245	</p>
				246
				247	<p>
				248	For example, the VMware SVGA gallium driver uses a special semi-fallback path
				249	for drawing with polygon stipple.
				250	Since the two passes are rendered with different vertex transformation
				251	implementations, the rendering doesn't appear as expected.
				252	Setting the SVGA_FORCE_SWTNL environment variable to 1 will force the
				253	driver to use the software vertex path all the time and clears up this issue.
				254	</p>
				255
				256	<p>
				257	According to the OpenGL invariance rules, there's no guarantee that
				258	the pixels produced by these two rendering states will match.
				259	To achieve invariance, both passes should enable polygon stipple and
				260	blending with appropriate patterns/modes to ensure the same fragments
				261	are produced in both passes.
				262	</p>
				263
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	264	<h2><u>Viewperf 12</u></h2>
				265
				266	<p>
				267	Note that Viewperf 12 only runs on 64-bit Windows 7 or later.
				268	</p>
				269
				270	<h3>catia-04</h3>
				271
				272	<p>
				273	One of the catia tests calls wglGetProcAddress() to get some
				274	GL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and some
				275	GL_NV_half_float functions (such as glMultiTexCoord3hNV).
				276	If the extension/function is not supported, wglGetProcAddress() can return NULL.
				277	Unfortunately, Viewperf doesn't check for null pointers and crashes when it
				278	later tries to use the pointer.
				279	</p>
				280
				281	<p>
				282	Another catia test uses OpenGL 3.1's primitive restart feature.
				283	But when Viewperf creates an OpenGL context, it doesn't request version 3.1
				284	If the driver returns version 3.0 or earlier all the calls related to primitive
				285	restart generate an OpenGL error.
				286	Some of the rendering is then incorrect.
				287	</p>
				288
				289
				290	<h3>energy-01</h3>
				291
				292	<p>
				293	This test creates a 3D luminance texture of size 1K x 1K x 1K.
				294	If the OpenGL driver/device doesn't support a texture of this size
				295	the glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY
				296	and all that's rendered is plain white polygons.
				297	Ideally, the test would use a proxy texture to determine the max 3D
				298	texture size. But it does not do that.
				299	</p>
				300
				301	<h3>maya-04</h3>
				302
				303	<p>
				304	This test generates many GL_INVALID_OPERATION errors in its calls to
				305	glUniform().
				306	Causes include:
				307	<ul>
				308	<li> Trying to set float uniforms with glUniformi()
				309	<li> Trying to set float uniforms with glUniform3f()
				310	<li> Trying to set matrix uniforms with glUniform() instead of glUniformMatrix().
				311	</ul>
				312	<p>
				313	Apparently, the indexes returned by glGetUniformLocation() were hard-coded
				314	into the application trace when it was created.
				315	Since different implementations of glGetUniformLocation() may return different
				316	values for any given uniform name, subsequent calls to glUniform() will be
				317	invalid since they refer to the wrong uniform variables.
				318	This causes many OpenGL errors and leads to incorrect rendering.
				319	</p>
				320
				321	<h3>medical-01</h3>
				322
				323	<p>
				324	This test uses a single GLSL fragment shader which contains a GLSL 1.20
				325	array initializer statement, but it neglects to specify
				326	<code>#version 120</code> at the top of the shader code.
				327	So, the shader does not compile and all that's rendered is plain white polygons.
				328	</p>
Brian Paul	3597a0d	2015-04-23 10:00:34 -0600	[diff] [blame]	329	<p>
				330	Also, the test tries to create a very large 3D texture that may exceed
				331	the device driver's limit.
				332	When this happens, the glTexImage3D call fails and all that's rendered is
				333	a white box.
				334	</p>
				335
Brian Paul	3db0317	2015-03-31 11:30:32 -0600	[diff] [blame]	336
				337	<h3>showcase-01</h3>
				338
				339	<p>
				340	This is actually a DX11 test based on Autodesk's Showcase product.
				341	As such, it won't run with Mesa.
				342	</p>
				343
Brian Paul	71ee003	2013-04-23 13:18:41 -0600	[diff] [blame]	344
Andreas Boll	b5da52a	2012-09-18 18:57:02 +0200	[diff] [blame]	345	</div>
Andreas Boll	ecd5c7c	2012-06-12 09:05:03 +0200	[diff] [blame]	346	</body>
				347	</html>