-<HTML>
-
-<TITLE>Viewperf Issues</TITLE>
-
-<link rel="stylesheet" type="text/css" href="mesa.css"></head>
-
-<BODY>
+<!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>
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>
-<h2>sw-02 tests 1, 2, 4</h2>
+<h2>sw-02 tests 1, 2, 4, 6</h2>
<p>
These tests depend on the
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>
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>
-</BODY>
-</HTML>
+</div>
+</body>
+</html>
projects / mesa.git / blobdiff