1Viewperf Issues
2===============
3
4This page lists known issues with `SPEC Viewperf
511 <https://www.spec.org/gwpg/gpc.static/vp11info.html>`__ and `SPEC
6Viewperf 12 <https://www.spec.org/gwpg/gpc.static/vp12info.html>`__ when
7running on Mesa-based drivers.
8
9The Viewperf data sets are basically GL API traces that are recorded
10from CAD applications, then replayed in the Viewperf framework.
11
12The primary problem with these traces is they blindly use features and
13OpenGL extensions that were supported by the OpenGL driver when the
14trace was recorded, but there's no checks to see if those features are
15supported by the driver when playing back the traces with Viewperf.
16
17These issues have been reported to the SPEC organization in the hope
18that they'll be fixed in the future.
19
20Viewperf 11
21-----------
22
23Some of the Viewperf 11 tests use a lot of memory. At least 2GB of RAM
24is recommended.
25
26Catia-03 test 2
27~~~~~~~~~~~~~~~
28
29This test creates over 38000 vertex buffer objects. On some systems this
30can exceed the maximum number of buffer allocations. Mesa generates
31GL_OUT_OF_MEMORY errors in this situation, but Viewperf does no error
32checking and continues. When this happens, some drawing commands become
33no-ops. This can also eventually lead to a segfault either in Viewperf
34or the Mesa driver.
35
36Catia-03 tests 3, 4, 8
37~~~~~~~~~~~~~~~~~~~~~~
38
39These tests use features of the
40`GL_NV_fragment_program2 <https://www.opengl.org/registry/specs/NV/fragment_program2.txt>`__
41and
42`GL_NV_vertex_program3 <https://www.opengl.org/registry/specs/NV/vertex_program3.txt>`__
43extensions without checking if the driver supports them.
44
45When Mesa tries to compile the vertex/fragment programs it generates
46errors (which Viewperf ignores). Subsequent drawing calls become no-ops
47and the rendering is incorrect.
48
49sw-02 tests 1, 2, 4, 6
50~~~~~~~~~~~~~~~~~~~~~~
51
52These tests depend on the
53`GL_NV_primitive_restart <https://www.opengl.org/registry/specs/NV/primitive_restart.txt>`__
54extension.
55
56If the Mesa driver doesn't support this extension the rendering will be
57incorrect and the test will fail.
58
59Also, the color of the line drawings in test 2 seem to appear in a
60random color. This is probably due to some uninitialized state
61somewhere.
62
63sw-02 test 6
64~~~~~~~~~~~~
65
66The lines drawn in this test appear in a random color. That's because
67texture mapping is enabled when the lines are drawn, but no texture
68image is defined (glTexImage2D() is called with pixels=NULL). Since GL
69says the contents of the texture image are undefined in that situation,
70we get a random color.
71
72Lightwave-01 test 3
73~~~~~~~~~~~~~~~~~~~
74
75This test uses a number of mipmapped textures, but the textures are
76incomplete because the last/smallest mipmap level (1 x 1 pixel) is never
77specified.
78
79A trace captured with `API
80trace <https://github.com/apitrace/apitrace>`__ shows this sequences of
81calls like this:
82
83::
84
85   2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
86   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))
87   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))
88   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))
89   [...]
90   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))
91   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))
92   2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
93   2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
94   2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
95   2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
96
97Note that one would expect call 2514 to be glTexImage(level=9, width=1,
98height=1) but it's not there.
99
100The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
101GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
102
103Later, these incomplete textures are bound before drawing calls.
104According to the GL specification, if a fragment program or fragment
105shader is being used, the sampler should return (0,0,0,1) ("black") when
106sampling from an incomplete texture. This is what Mesa does and the
107resulting rendering is darker than it should be.
108
109It appears that NVIDIA's driver (and possibly AMD's driver) detects this
110case and returns (1,1,1,1) (white) which causes the rendering to appear
111brighter and match the reference image (however, AMD's rendering is
112*much* brighter than NVIDIA's).
113
114If the fallback texture created in \_mesa_get_fallback_texture() is
115initialized to be full white instead of full black the rendering appears
116correct. However, we have no plans to implement this work-around in
117Mesa.
118
119Maya-03 test 2
120~~~~~~~~~~~~~~
121
122This test makes some unusual calls to glRotate. For example:
123
124::
125
126   glRotate(50, 50, 50, 1);
127   glRotate(100, 100, 100, 1);
128   glRotate(52, 52, 52, 1);
129
130These unusual values lead to invalid modelview matrices. For example,
131the last glRotate command above produces this matrix with Mesa:
132
133::
134
135   1.08536e+24 2.55321e-23 -0.000160389 0
136   5.96937e-25 1.08536e+24 103408 0
137   103408 -0.000160389 1.74755e+09 0
138   0 0 0 nan
139
140and with NVIDIA's OpenGL:
141
142::
143
144   1.4013e-45 0 -nan 0
145   0 1.4013e-45 1.4013e-45 0
146   1.4013e-45 -nan 1.4013e-45 0
147   0 0 0 1.4013e-45
148
149This causes the object in question to be drawn in a strange orientation
150and with a semi-random color (between white and black) since GL_FOG is
151enabled.
152
153Proe-05 test 1
154~~~~~~~~~~~~~~
155
156This uses depth testing but there's two problems:
157
158#. The glXChooseFBConfig() call doesn't request a depth buffer
159#. The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the
160   depth buffer
161
162If the chosen visual does not have a depth buffer, you'll see the
163wireframe car model but it won't be rendered correctly.
164
165If (by luck) the chosen visual has a depth buffer, its initial contents
166will be undefined so you may or may not see parts of the model.
167
168Interestingly, with NVIDIA's driver most visuals happen to have a depth
169buffer and apparently the contents are initialized to 1.0 by default so
170this test just happens to work with their drivers.
171
172Finally, even if a depth buffer was requested and the
173glClear(GL_COLOR_BUFFER_BIT) calls were changed to
174glClear(GL_COLOR_BUFFER_BIT \| GL_DEPTH_BUFFER_BIT) the problem still
175wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when glClear is
176called so clearing the depth buffer would be a no-op anyway.
177
178Proe-05 test 6
179~~~~~~~~~~~~~~
180
181This test draws an engine model with a two-pass algorithm. The first
182pass is drawn with polygon stipple enabled. The second pass is drawn
183without polygon stipple but with blending and GL_DEPTH_FUNC=GL_LEQUAL.
184If either of the two passes happen to use a software fallback of some
185sort, the Z values of fragments may be different between the two passes.
186This leads to incorrect rendering.
187
188For example, the VMware SVGA gallium driver uses a special semi-fallback
189path for drawing with polygon stipple. Since the two passes are rendered
190with different vertex transformation implementations, the rendering
191doesn't appear as expected. Setting the SVGA_FORCE_SWTNL environment
192variable to 1 will force the driver to use the software vertex path all
193the time and clears up this issue.
194
195According to the OpenGL invariance rules, there's no guarantee that the
196pixels produced by these two rendering states will match. To achieve
197invariance, both passes should enable polygon stipple and blending with
198appropriate patterns/modes to ensure the same fragments are produced in
199both passes.
200
201Viewperf 12
202-----------
203
204Note that Viewperf 12 only runs on 64-bit Windows 7 or later.
205
206catia-04
207~~~~~~~~
208
209One of the catia tests calls wglGetProcAddress() to get some
210GL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and
211some GL_NV_half_float functions (such as glMultiTexCoord3hNV). If the
212extension/function is not supported, wglGetProcAddress() can return
213NULL. Unfortunately, Viewperf doesn't check for null pointers and
214crashes when it later tries to use the pointer.
215
216Another catia test uses OpenGL 3.1's primitive restart feature. But when
217Viewperf creates an OpenGL context, it doesn't request version 3.1 If
218the driver returns version 3.0 or earlier all the calls related to
219primitive restart generate an OpenGL error. Some of the rendering is
220then incorrect.
221
222energy-01
223~~~~~~~~~
224
225This test creates a 3D luminance texture of size 1K x 1K x 1K. If the
226OpenGL driver/device doesn't support a texture of this size the
227glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY
228and all that's rendered is plain white polygons. Ideally, the test would
229use a proxy texture to determine the max 3D texture size. But it does
230not do that.
231
232maya-04
233~~~~~~~
234
235This test generates many GL_INVALID_OPERATION errors in its calls to
236glUniform(). Causes include:
237
238-  Trying to set float uniforms with glUniformi()
239-  Trying to set float uniforms with glUniform3f()
240-  Trying to set matrix uniforms with glUniform() instead of
241   glUniformMatrix().
242
243Apparently, the indexes returned by glGetUniformLocation() were
244hard-coded into the application trace when it was created. Since
245different implementations of glGetUniformLocation() may return different
246values for any given uniform name, subsequent calls to glUniform() will
247be invalid since they refer to the wrong uniform variables. This causes
248many OpenGL errors and leads to incorrect rendering.
249
250medical-01
251~~~~~~~~~~
252
253This test uses a single GLSL fragment shader which contains a GLSL 1.20
254array initializer statement, but it neglects to specify ``#version 120``
255at the top of the shader code. So, the shader does not compile and all
256that's rendered is plain white polygons.
257
258Also, the test tries to create a very large 3D texture that may exceed
259the device driver's limit. When this happens, the glTexImage3D call
260fails and all that's rendered is a white box.
261
262showcase-01
263~~~~~~~~~~~
264
265This is actually a DX11 test based on Autodesk's Showcase product. As
266such, it won't run with Mesa.
267