Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / mesa3d / 728240b64d1263bfe2f6d52c3643f70b5719ccbc / . / docs / viewperf.html
blob: 3bbe1978ab88c7041714241bb089d1e4cf25a30e [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
21<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
22when running on Mesa-based drivers.
23</p>
24
25<p>
26The Viewperf data sets are basically GL API traces that are recorded from
27CAD applications, then replayed in the Viewperf framework.
28</p>
29
30<p>
31The primary problem with these traces is they blindly use features and
32OpenGL extensions that were supported by the OpenGL driver when the trace
33was recorded,
34but there's no checks to see if those features are supported by the driver
35when playing back the traces with Viewperf.
36</p>
37
38<p>
39These issues have been reported to the SPEC organization in the hope that
40they'll be fixed in the future.
41</p>
42
Brian Paul0615eb82012-04-19 14:38:45 -0600[diff] [blame]43<p>
44Some of the Viewperf tests use a lot of memory.
45At least 2GB of RAM is recommended.
46</p>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]47
48
Brian Paul9c0d7822011-11-09 13:32:18 -0700[diff] [blame]49<h2>Catia-03 test 2</h2>
50
51<p>
52This test creates over 38000 vertex buffer objects. On some systems
53this can exceed the maximum number of buffer allocations. Mesa
54generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
55does no error checking and continues. When this happens, some drawing
56commands become no-ops. This can also eventually lead to a segfault
57either in Viewperf or the Mesa driver.
58</p>
59
60
61
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]62<h2>Catia-03 tests 3, 4, 8</h2>
63
64<p>
65These tests use features of the
66<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
67target="_main">
68GL_NV_fragment_program2</a> and
69<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
70target="_main">
71GL_NV_vertex_program3</a> extensions without checking if the driver supports
72them.
73</p>
74<p>
75When Mesa tries to compile the vertex/fragment programs it generates errors
76(which Viewperf ignores).
77Subsequent drawing calls become no-ops and the rendering is incorrect.
78</p>
79
80
81
Brian Paul0fd41652012-04-11 11:53:33 -0600[diff] [blame]82<h2>sw-02 tests 1, 2, 4, 6</h2>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]83
84<p>
85These tests depend on the
86<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
87target="_main">GL_NV_primitive_restart</a> extension.
88</p>
89
90<p>
91If the Mesa driver doesn't support this extension the rendering will
92be incorrect and the test will fail.
93</p>
94
Brian Paula0c380a2012-05-01 15:49:31 -0600[diff] [blame]95<p>
96Also, the color of the line drawings in test 2 seem to appear in a random
97color. This is probably due to some uninitialized state somewhere.
98</p>
99
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]100
Brian Paul0fd41652012-04-11 11:53:33 -0600[diff] [blame]101
102<h2>sw-02 test 6</h2>
103
104<p>
105The lines drawn in this test appear in a random color.
106That's because texture mapping is enabled when the lines are drawn, but no
107texture image is defined (glTexImage2D() is called with pixels=NULL).
108Since GL says the contents of the texture image are undefined in that
109situation, we get a random color.
110</p>
111
112
113
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]114<h2>Lightwave-01 test 3</h2>
115
116<p>
117This test uses a number of mipmapped textures, but the textures are
118incomplete because the last/smallest mipmap level (1 x 1 pixel) is
119never specified.
120</p>
121
122<p>
123A trace captured with
124<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
125shows this sequences of calls like this:
126
127<pre>
1282504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
1292505 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))
1302506 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))
1312507 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[...]
1332512 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))
1342513 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))
1352514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
1362515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
1372516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
1382517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
139</pre>
140
141<p>
142Note that one would expect call 2514 to be glTexImage(level=9, width=1,
143height=1) but it's not there.
144</p>
145
146<p>
147The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
148GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
149</p>
150
151<p>
152Later, these incomplete textures are bound before drawing calls.
153According to the GL specification, if a fragment program or fragment shader
154is being used, the sampler should return (0,0,0,1) ("black") when sampling
155from an incomplete texture.
156This is what Mesa does and the resulting rendering is darker than it should
157be.
158</p>
159
160<p>
161It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
162and returns (1,1,1,1) (white) which causes the rendering to appear brighter
163and match the reference image (however, AMD's rendering is <em>much</em>
164brighter than NVIDIA's).
165</p>
166
167<p>
168If the fallback texture created in _mesa_get_fallback_texture() is
169initialized to be full white instead of full black the rendering appears
170correct.
171However, we have no plans to implement this work-around in Mesa.
Brian Paul286e50a2012-04-13 14:31:16 -0600[diff] [blame]172</p>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]173
Brian Paul286e50a2012-04-13 14:31:16 -0600[diff] [blame]174
175<h2>Maya-03 test 2</h2>
176
177<p>
178This test makes some unusual calls to glRotate. For example:
179</p>
180<pre>
181glRotate(50, 50, 50, 1);
182glRotate(100, 100, 100, 1);
183glRotate(52, 52, 52, 1);
184</pre>
185<p>
186These unusual values lead to invalid modelview matrices.
187For example, the last glRotate command above produces this matrix with Mesa:
188<pre>
1891.08536e+24 2.55321e-23 -0.000160389 0
1905.96937e-25 1.08536e+24 103408 0
191103408 -0.000160389 1.74755e+09 0
1920 0 0 nan
193</pre>
194and with NVIDIA's OpenGL:
195<pre>
1961.4013e-45 0 -nan 0
1970 1.4013e-45 1.4013e-45 0
1981.4013e-45 -nan 1.4013e-45 0
1990 0 0 1.4013e-45
200</pre>
201<p>
202This causes the object in question to be drawn in a strange orientation
203and with a semi-random color (between white and black) since GL_FOG is enabled.
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]204</p>
205
Brian Paul728240b2013-03-08 10:32:39 -0700[diff] [blame^]206
207<h2>Proe-05 test 1</h2>
208
209<p>
210This 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>
216If the chosen visual does not have a depth buffer, you'll see the wireframe
217car model but it won't be rendered correctly.
218</p>
219If (by luck) the chosen visual has a depth buffer, its initial contents
220will be undefined so you may or may not see parts of the model.
221<p>
222Interestingly, with NVIDIA's driver most visuals happen to have a depth buffer
223and apparently the contents are initialized to 1.0 by default so this test
224just happens to work with their drivers.
225</p>
226
227<p>
228Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT)
229calls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
230the problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when
231glClear is called so clearing the depth buffer would be a no-op anyway.
232</p>
233
234
Andreas Bollb5da52a2012-09-18 18:57:02 +0200[diff] [blame]235</div>
Andreas Bollecd5c7c2012-06-12 09:05:03 +0200[diff] [blame]236</body>
237</html>