Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / mesa3d / ecd5c7ceb8e4c8841b2708e5ab7efa145583f8c2 / . / docs / viewperf.html
blob: 6c3faf68ce368b17e6ccfb06f806f555d2475113 [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
10<h1>Viewperf Issues</h1>
11
12<p>
13This page lists known issues with
14<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
15when running on Mesa-based drivers.
16</p>
17
18<p>
19The Viewperf data sets are basically GL API traces that are recorded from
20CAD applications, then replayed in the Viewperf framework.
21</p>
22
23<p>
24The primary problem with these traces is they blindly use features and
25OpenGL extensions that were supported by the OpenGL driver when the trace
26was recorded,
27but there's no checks to see if those features are supported by the driver
28when playing back the traces with Viewperf.
29</p>
30
31<p>
32These issues have been reported to the SPEC organization in the hope that
33they'll be fixed in the future.
34</p>
35
Brian Paul0615eb82012-04-19 14:38:45 -0600[diff] [blame]36<p>
37Some of the Viewperf tests use a lot of memory.
38At least 2GB of RAM is recommended.
39</p>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]40
41
Brian Paul9c0d7822011-11-09 13:32:18 -0700[diff] [blame]42<h2>Catia-03 test 2</h2>
43
44<p>
45This test creates over 38000 vertex buffer objects. On some systems
46this can exceed the maximum number of buffer allocations. Mesa
47generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
48does no error checking and continues. When this happens, some drawing
49commands become no-ops. This can also eventually lead to a segfault
50either in Viewperf or the Mesa driver.
51</p>
52
53
54
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]55<h2>Catia-03 tests 3, 4, 8</h2>
56
57<p>
58These tests use features of the
59<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
60target="_main">
61GL_NV_fragment_program2</a> and
62<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
63target="_main">
64GL_NV_vertex_program3</a> extensions without checking if the driver supports
65them.
66</p>
67<p>
68When Mesa tries to compile the vertex/fragment programs it generates errors
69(which Viewperf ignores).
70Subsequent drawing calls become no-ops and the rendering is incorrect.
71</p>
72
73
74
Brian Paul0fd41652012-04-11 11:53:33 -0600[diff] [blame]75<h2>sw-02 tests 1, 2, 4, 6</h2>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]76
77<p>
78These tests depend on the
79<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
80target="_main">GL_NV_primitive_restart</a> extension.
81</p>
82
83<p>
84If the Mesa driver doesn't support this extension the rendering will
85be incorrect and the test will fail.
86</p>
87
Brian Paula0c380a2012-05-01 15:49:31 -0600[diff] [blame]88<p>
89Also, the color of the line drawings in test 2 seem to appear in a random
90color. This is probably due to some uninitialized state somewhere.
91</p>
92
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]93
Brian Paul0fd41652012-04-11 11:53:33 -0600[diff] [blame]94
95<h2>sw-02 test 6</h2>
96
97<p>
98The lines drawn in this test appear in a random color.
99That's because texture mapping is enabled when the lines are drawn, but no
100texture image is defined (glTexImage2D() is called with pixels=NULL).
101Since GL says the contents of the texture image are undefined in that
102situation, we get a random color.
103</p>
104
105
106
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]107<h2>Lightwave-01 test 3</h2>
108
109<p>
110This test uses a number of mipmapped textures, but the textures are
111incomplete because the last/smallest mipmap level (1 x 1 pixel) is
112never specified.
113</p>
114
115<p>
116A trace captured with
117<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
118shows this sequences of calls like this:
119
120<pre>
1212504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
1222505 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))
1232506 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))
1242507 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))
125[...]
1262512 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))
1272513 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))
1282514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
1292515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
1302516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
1312517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
132</pre>
133
134<p>
135Note that one would expect call 2514 to be glTexImage(level=9, width=1,
136height=1) but it's not there.
137</p>
138
139<p>
140The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
141GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
142</p>
143
144<p>
145Later, these incomplete textures are bound before drawing calls.
146According to the GL specification, if a fragment program or fragment shader
147is being used, the sampler should return (0,0,0,1) ("black") when sampling
148from an incomplete texture.
149This is what Mesa does and the resulting rendering is darker than it should
150be.
151</p>
152
153<p>
154It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
155and returns (1,1,1,1) (white) which causes the rendering to appear brighter
156and match the reference image (however, AMD's rendering is <em>much</em>
157brighter than NVIDIA's).
158</p>
159
160<p>
161If the fallback texture created in _mesa_get_fallback_texture() is
162initialized to be full white instead of full black the rendering appears
163correct.
164However, we have no plans to implement this work-around in Mesa.
Brian Paul286e50a2012-04-13 14:31:16 -0600[diff] [blame]165</p>
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]166
Brian Paul286e50a2012-04-13 14:31:16 -0600[diff] [blame]167
168<h2>Maya-03 test 2</h2>
169
170<p>
171This test makes some unusual calls to glRotate. For example:
172</p>
173<pre>
174glRotate(50, 50, 50, 1);
175glRotate(100, 100, 100, 1);
176glRotate(52, 52, 52, 1);
177</pre>
178<p>
179These unusual values lead to invalid modelview matrices.
180For example, the last glRotate command above produces this matrix with Mesa:
181<pre>
1821.08536e+24 2.55321e-23 -0.000160389 0
1835.96937e-25 1.08536e+24 103408 0
184103408 -0.000160389 1.74755e+09 0
1850 0 0 nan
186</pre>
187and with NVIDIA's OpenGL:
188<pre>
1891.4013e-45 0 -nan 0
1900 1.4013e-45 1.4013e-45 0
1911.4013e-45 -nan 1.4013e-45 0
1920 0 0 1.4013e-45
193</pre>
194<p>
195This causes the object in question to be drawn in a strange orientation
196and with a semi-random color (between white and black) since GL_FOG is enabled.
Brian Paulc60eb632011-10-20 15:13:17 -0600[diff] [blame]197</p>
198
199
Andreas Bollecd5c7c2012-06-12 09:05:03 +0200[diff] [blame^]200</body>
201</html>