268 lines
8.6 KiB
HTML
268 lines
8.6 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||
|
|
<title>Viewperf Issues</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="mesa.css">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<div class="header">
|
||
|
|
<h1>The Mesa 3D Graphics Library</h1>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<iframe src="contents.html"></iframe>
|
||
|
|
<div class="content">
|
||
|
|
|
||
|
|
<h1>Viewperf Issues</h1>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This page lists known issues with
|
||
|
|
<a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a>
|
||
|
|
when running on Mesa-based drivers.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The Viewperf data sets are basically GL API traces that are recorded from
|
||
|
|
CAD applications, then replayed in the Viewperf framework.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The primary problem with these traces is they blindly use features and
|
||
|
|
OpenGL extensions that were supported by the OpenGL driver when the trace
|
||
|
|
was recorded,
|
||
|
|
but there's no checks to see if those features are supported by the driver
|
||
|
|
when playing back the traces with Viewperf.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
These issues have been reported to the SPEC organization in the hope that
|
||
|
|
they'll be fixed in the future.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Some of the Viewperf tests use a lot of memory.
|
||
|
|
At least 2GB of RAM is recommended.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Catia-03 test 2</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This test creates over 38000 vertex buffer objects. On some systems
|
||
|
|
this can exceed the maximum number of buffer allocations. Mesa
|
||
|
|
generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf
|
||
|
|
does no error checking and continues. When this happens, some drawing
|
||
|
|
commands become no-ops. This can also eventually lead to a segfault
|
||
|
|
either in Viewperf or the Mesa driver.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Catia-03 tests 3, 4, 8</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
These tests use features of the
|
||
|
|
<a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt"
|
||
|
|
target="_main">
|
||
|
|
GL_NV_fragment_program2</a> and
|
||
|
|
<a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt"
|
||
|
|
target="_main">
|
||
|
|
GL_NV_vertex_program3</a> extensions without checking if the driver supports
|
||
|
|
them.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
When Mesa tries to compile the vertex/fragment programs it generates errors
|
||
|
|
(which Viewperf ignores).
|
||
|
|
Subsequent drawing calls become no-ops and the rendering is incorrect.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2>sw-02 tests 1, 2, 4, 6</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
These tests depend on the
|
||
|
|
<a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt"
|
||
|
|
target="_main">GL_NV_primitive_restart</a> extension.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
If the Mesa driver doesn't support this extension the rendering will
|
||
|
|
be incorrect and the test will fail.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Also, the color of the line drawings in test 2 seem to appear in a random
|
||
|
|
color. This is probably due to some uninitialized state somewhere.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2>sw-02 test 6</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The lines drawn in this test appear in a random color.
|
||
|
|
That's because texture mapping is enabled when the lines are drawn, but no
|
||
|
|
texture image is defined (glTexImage2D() is called with pixels=NULL).
|
||
|
|
Since GL says the contents of the texture image are undefined in that
|
||
|
|
situation, we get a random color.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Lightwave-01 test 3</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This test uses a number of mipmapped textures, but the textures are
|
||
|
|
incomplete because the last/smallest mipmap level (1 x 1 pixel) is
|
||
|
|
never specified.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
A trace captured with
|
||
|
|
<a href="https://github.com/apitrace/apitrace" target="_main">API trace</a>
|
||
|
|
shows this sequences of calls like this:
|
||
|
|
|
||
|
|
<pre>
|
||
|
|
2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55)
|
||
|
|
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))
|
||
|
|
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))
|
||
|
|
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))
|
||
|
|
[...]
|
||
|
|
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))
|
||
|
|
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))
|
||
|
|
2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
|
||
|
|
2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT)
|
||
|
|
2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT)
|
||
|
|
2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Note that one would expect call 2514 to be glTexImage(level=9, width=1,
|
||
|
|
height=1) but it's not there.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's
|
||
|
|
GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Later, these incomplete textures are bound before drawing calls.
|
||
|
|
According to the GL specification, if a fragment program or fragment shader
|
||
|
|
is being used, the sampler should return (0,0,0,1) ("black") when sampling
|
||
|
|
from an incomplete texture.
|
||
|
|
This is what Mesa does and the resulting rendering is darker than it should
|
||
|
|
be.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
It appears that NVIDIA's driver (and possibly AMD's driver) detects this case
|
||
|
|
and returns (1,1,1,1) (white) which causes the rendering to appear brighter
|
||
|
|
and match the reference image (however, AMD's rendering is <em>much</em>
|
||
|
|
brighter than NVIDIA's).
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
If the fallback texture created in _mesa_get_fallback_texture() is
|
||
|
|
initialized to be full white instead of full black the rendering appears
|
||
|
|
correct.
|
||
|
|
However, we have no plans to implement this work-around in Mesa.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Maya-03 test 2</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This test makes some unusual calls to glRotate. For example:
|
||
|
|
</p>
|
||
|
|
<pre>
|
||
|
|
glRotate(50, 50, 50, 1);
|
||
|
|
glRotate(100, 100, 100, 1);
|
||
|
|
glRotate(52, 52, 52, 1);
|
||
|
|
</pre>
|
||
|
|
<p>
|
||
|
|
These unusual values lead to invalid modelview matrices.
|
||
|
|
For example, the last glRotate command above produces this matrix with Mesa:
|
||
|
|
<pre>
|
||
|
|
1.08536e+24 2.55321e-23 -0.000160389 0
|
||
|
|
5.96937e-25 1.08536e+24 103408 0
|
||
|
|
103408 -0.000160389 1.74755e+09 0
|
||
|
|
0 0 0 nan
|
||
|
|
</pre>
|
||
|
|
and with NVIDIA's OpenGL:
|
||
|
|
<pre>
|
||
|
|
1.4013e-45 0 -nan 0
|
||
|
|
0 1.4013e-45 1.4013e-45 0
|
||
|
|
1.4013e-45 -nan 1.4013e-45 0
|
||
|
|
0 0 0 1.4013e-45
|
||
|
|
</pre>
|
||
|
|
<p>
|
||
|
|
This causes the object in question to be drawn in a strange orientation
|
||
|
|
and with a semi-random color (between white and black) since GL_FOG is enabled.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Proe-05 test 1</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This uses depth testing but there's two problems:
|
||
|
|
<ol>
|
||
|
|
<li>The glXChooseFBConfig() call doesn't request a depth buffer
|
||
|
|
<li>The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer
|
||
|
|
</ol>
|
||
|
|
<p>
|
||
|
|
If the chosen visual does not have a depth buffer, you'll see the wireframe
|
||
|
|
car model but it won't be rendered correctly.
|
||
|
|
</p>
|
||
|
|
If (by luck) the chosen visual has a depth buffer, its initial contents
|
||
|
|
will be undefined so you may or may not see parts of the model.
|
||
|
|
<p>
|
||
|
|
Interestingly, with NVIDIA's driver most visuals happen to have a depth buffer
|
||
|
|
and apparently the contents are initialized to 1.0 by default so this test
|
||
|
|
just happens to work with their drivers.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Finally, even if a depth buffer was requested and the glClear(GL_COLOR_BUFFER_BIT)
|
||
|
|
calls were changed to glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
|
||
|
|
the problem still wouldn't be fixed because GL_DEPTH_WRITEMASK=GL_FALSE when
|
||
|
|
glClear is called so clearing the depth buffer would be a no-op anyway.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2>Proe-05 test 6</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This test draws an engine model with a two-pass algorithm.
|
||
|
|
The first pass is drawn with polygon stipple enabled.
|
||
|
|
The second pass is drawn without polygon stipple but with blending
|
||
|
|
and GL_DEPTH_FUNC=GL_LEQUAL.
|
||
|
|
If either of the two passes happen to use a software fallback of some
|
||
|
|
sort, the Z values of fragments may be different between the two passes.
|
||
|
|
This leads to incorrect rendering.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
For example, the VMware SVGA gallium driver uses a special semi-fallback path
|
||
|
|
for drawing with polygon stipple.
|
||
|
|
Since the two passes are rendered with different vertex transformation
|
||
|
|
implementations, the rendering doesn't appear as expected.
|
||
|
|
Setting the SVGA_FORCE_SWTNL environment variable to 1 will force the
|
||
|
|
driver to use the software vertex path all the time and clears up this issue.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
According to the OpenGL invariance rules, there's no guarantee that
|
||
|
|
the pixels produced by these two rendering states will match.
|
||
|
|
To achieve invariance, both passes should enable polygon stipple and
|
||
|
|
blending with appropriate patterns/modes to ensure the same fragments
|
||
|
|
are produced in both passes.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|