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

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