viewperf.html revision 0fd4165261311fb36c98885edb7331df29eec09d 
1<HTML>
2
3<TITLE>Viewperf Issues</TITLE>
4
5<link rel="stylesheet" type="text/css" href="mesa.css"></head>
6
7<BODY>
8
9<h1>Viewperf Issues</h1>
10
11<p>
12This page lists known issues with
13<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
14when running on Mesa-based drivers.
15</p>
16
17<p>
18The Viewperf data sets are basically GL API traces that are recorded from
19CAD applications, then replayed in the Viewperf framework.
20</p>
21
22<p>
23The primary problem with these traces is they blindly use features and
24OpenGL extensions that were supported by the OpenGL driver when the trace
25was recorded,
26but there's no checks to see if those features are supported by the driver
27when playing back the traces with Viewperf.
28</p>
29
30<p>
31These issues have been reported to the SPEC organization in the hope that
32they'll be fixed in the future.
33</p>
34
35
36
37<h2>Catia-03 test 2</h2>
38
39<p>
40This test creates over 38000 vertex buffer objects.  On some systems
41this can exceed the maximum number of buffer allocations.  Mesa
42generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
43does no error checking and continues.  When this happens, some drawing
44commands become no-ops.  This can also eventually lead to a segfault
45either in Viewperf or the Mesa driver.
46</p>
47
48
49
50<h2>Catia-03 tests 3, 4, 8</h2>
51
52<p>
53These tests use features of the
54<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
55target="_main">
56GL_NV_fragment_program2</a> and
57<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
58target="_main">
59GL_NV_vertex_program3</a> extensions without checking if the driver supports
60them.
61</p>
62<p>
63When Mesa tries to compile the vertex/fragment programs it generates errors
64(which Viewperf ignores).
65Subsequent drawing calls become no-ops and the rendering is incorrect.
66</p>
67
68
69
70<h2>sw-02 tests 1, 2, 4, 6</h2>
71
72<p>
73These tests depend on the
74<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
75target="_main">GL_NV_primitive_restart</a> extension.
76</p>
77
78<p>
79If the Mesa driver doesn't support this extension the rendering will
80be incorrect and the test will fail.
81</p>
82
83
84
85<h2>sw-02 test 6</h2>
86
87<p>
88The lines drawn in this test appear in a random color.
89That's because texture mapping is enabled when the lines are drawn, but no
90texture image is defined (glTexImage2D() is called with pixels=NULL).
91Since GL says the contents of the texture image are undefined in that
92situation, we get a random color.
93</p>
94
95
96
97<h2>Lightwave-01 test 3</h2>
98
99<p>
100This test uses a number of mipmapped textures, but the textures are
101incomplete because the last/smallest mipmap level (1 x 1 pixel) is
102never specified.
103</p>
104
105<p>
106A trace captured with
107<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
108shows this sequences of calls like this:
109
110<pre>
1112504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
1122505 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))
1132506 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))
1142507 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))
115[...]
1162512 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))
1172513 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))
1182514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
1192515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
1202516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
1212517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
122</pre>
123
124<p>
125Note that one would expect call 2514 to be glTexImage(level=9, width=1,
126height=1) but it's not there.
127</p>
128
129<p>
130The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
131GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
132</p>
133
134<p>
135Later, these incomplete textures are bound before drawing calls.
136According to the GL specification, if a fragment program or fragment shader
137is being used, the sampler should return (0,0,0,1) ("black") when sampling
138from an incomplete texture.
139This is what Mesa does and the resulting rendering is darker than it should
140be.
141</p>
142
143<p>
144It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
145and returns (1,1,1,1) (white) which causes the rendering to appear brighter
146and match the reference image (however, AMD's rendering is <em>much</em>
147brighter than NVIDIA's).
148</p>
149
150<p>
151If the fallback texture created in _mesa_get_fallback_texture() is
152initialized to be full white instead of full black the rendering appears
153correct.
154However, we have no plans to implement this work-around in Mesa.
155
156</p>
157
158
159</BODY>
160</HTML>
161