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