1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
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">
11 <h1>The Mesa
3D Graphics Library
</h1>
14 <iframe src=
"contents.html"></iframe>
17 <h1>Viewperf Issues
</h1>
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>
22 and
<a href=
"https://www.spec.org/gwpg/gpc.static/vp12info.html" target=
"_main">SPEC Viewperf
12</a>
23 when running on Mesa-based drivers.
27 The Viewperf data sets are basically GL API traces that are recorded from
28 CAD applications, then replayed in the Viewperf framework.
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
35 but there's no checks to see if those features are supported by the driver
36 when playing back the traces with Viewperf.
40 These issues have been reported to the SPEC organization in the hope that
41 they'll be fixed in the future.
44 <h2><u>Viewperf
11</u></h2>
47 Some of the Viewperf
11 tests use a lot of memory.
48 At least
2GB of RAM is recommended.
52 <h3>Catia-
03 test
2</h3>
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.
65 <h3>Catia-
03 tests
3,
4,
8</h3>
68 These tests use features of the
69 <a href=
"http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
71 GL_NV_fragment_program2
</a> and
72 <a href=
"http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
74 GL_NV_vertex_program3
</a> extensions without checking if the driver supports
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.
85 <h3>sw-
02 tests
1,
2,
4,
6</h3>
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.
94 If the Mesa driver doesn't support this extension the rendering will
95 be incorrect and the test will fail.
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.
105 <h3>sw-
02 test
6</h3>
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.
117 <h3>Lightwave-
01 test
3</h3>
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
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:
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))
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)
145 Note that one would expect call
2514 to be glTexImage(level=
9, width=
1,
146 height=
1) but it's not there.
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.
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
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).
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
174 However, we have no plans to implement this work-around in Mesa.
178 <h3>Maya-
03 test
2</h3>
181 This test makes some unusual calls to glRotate. For example:
184 glRotate(
50,
50,
50,
1);
185 glRotate(
100,
100,
100,
1);
186 glRotate(
52,
52,
52,
1);
189 These unusual values lead to invalid modelview matrices.
190 For example, the last glRotate command above produces this matrix with Mesa:
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
197 and with NVIDIA's OpenGL:
200 0 1.4013e-45 1.4013e-45 0
201 1.4013e-45 -nan
1.4013e-45 0
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.
210 <h3>Proe-
05 test
1</h3>
213 This uses depth testing but there's two problems:
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
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.
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.
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.
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.
238 <h3>Proe-
05 test
6</h3>
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.
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.
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.
267 <h2><u>Viewperf
12</u></h2>
270 Note that Viewperf
12 only runs on
64-bit Windows
7 or later.
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.
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.
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.
307 This test generates many GL_INVALID_OPERATION errors in its calls to
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().
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.
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.
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
343 This is actually a DX11 test based on Autodesk's Showcase product.
344 As such, it won't run with Mesa.