X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=docs%2Fviewperf.html;h=ae771ee6eff384a5f0426cac91638d885f08016c;hb=428bed3bded5426d621cbbb1c3161c8984f0779d;hp=ab2fd67ef6069ff701fbde3d1fed64ed3953501b;hpb=b5da52ac581c0f0a6587a489198cd02247b6b931;p=mesa.git diff --git a/docs/viewperf.html b/docs/viewperf.html index ab2fd67ef60..ae771ee6eff 100644 --- a/docs/viewperf.html +++ b/docs/viewperf.html @@ -8,7 +8,7 @@
This page lists known issues with -SPEC Viewperf 11 +SPEC Viewperf 11 +and SPEC Viewperf 12 when running on Mesa-based drivers.
@@ -40,13 +41,15 @@ These issues have been reported to the SPEC organization in the hope that they'll be fixed in the future. +-Some of the Viewperf tests use a lot of memory. +Some of the Viewperf 11 tests use a lot of memory. At least 2GB of RAM is recommended.
-This test creates over 38000 vertex buffer objects. On some systems @@ -59,17 +62,14 @@ either in Viewperf or the Mesa driver. -
These tests use features of the - -GL_NV_fragment_program2 and - -GL_NV_vertex_program3 extensions without checking if the driver supports -them. +GL_NV_fragment_program2 +and +GL_NV_vertex_program3 +extensions without checking if the driver supports them.
When Mesa tries to compile the vertex/fragment programs it generates errors @@ -79,12 +79,12 @@ Subsequent drawing calls become no-ops and the rendering is incorrect. -
These tests depend on the -GL_NV_primitive_restart extension. +GL_NV_primitive_restart +extension.
@@ -99,7 +99,7 @@ color. This is probably due to some uninitialized state somewhere. -
The lines drawn in this test appear in a random color. @@ -111,7 +111,7 @@ situation, we get a random color. -
This test uses a number of mipmapped textures, but the textures are @@ -121,7 +121,7 @@ never specified.
A trace captured with -API trace +API trace shows this sequences of calls like this:
@@ -172,7 +172,7 @@ However, we have no plans to implement this work-around in Mesa. -Maya-03 test 2
+Maya-03 test 2
This test makes some unusual calls to glRotate. For example: @@ -186,23 +186,162 @@ glRotate(52, 52, 52, 1); These unusual values lead to invalid modelview matrices. For example, the last glRotate command above produces this matrix with Mesa:
-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 +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 nanand with NVIDIA's OpenGL:-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 +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-45This 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.
+ +Proe-05 test 1
+ ++This uses depth testing but there's two problems: +
+
+- The glXChooseFBConfig() call doesn't request a depth buffer +
- The test never calls glClear(GL_DEPTH_BUFFER_BIT) to initialize the depth buffer +
+If the chosen visual does not have a depth buffer, you'll see the wireframe +car model but it won't be rendered correctly. +
+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. ++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. +
+ ++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. +
+ + +Proe-05 test 6
+ ++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. +
+ ++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. +
+ ++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. +
+ +Viewperf 12
+ ++Note that Viewperf 12 only runs on 64-bit Windows 7 or later. +
+ +catia-04
+ ++One of the catia tests calls wglGetProcAddress() to get some +GL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and some +GL_NV_half_float functions (such as glMultiTexCoord3hNV). +If the extension/function is not supported, wglGetProcAddress() can return NULL. +Unfortunately, Viewperf doesn't check for null pointers and crashes when it +later tries to use the pointer. +
+ ++Another catia test uses OpenGL 3.1's primitive restart feature. +But when Viewperf creates an OpenGL context, it doesn't request version 3.1 +If the driver returns version 3.0 or earlier all the calls related to primitive +restart generate an OpenGL error. +Some of the rendering is then incorrect. +
+ + +energy-01
+ ++This test creates a 3D luminance texture of size 1K x 1K x 1K. +If the OpenGL driver/device doesn't support a texture of this size +the glTexImage3D() call will fail with GL_INVALID_VALUE or GL_OUT_OF_MEMORY +and all that's rendered is plain white polygons. +Ideally, the test would use a proxy texture to determine the max 3D +texture size. But it does not do that. +
+ +maya-04
+ ++This test generates many GL_INVALID_OPERATION errors in its calls to +glUniform(). +Causes include: +
+Apparently, the indexes returned by glGetUniformLocation() were hard-coded +into the application trace when it was created. +Since different implementations of glGetUniformLocation() may return different +values for any given uniform name, subsequent calls to glUniform() will be +invalid since they refer to the wrong uniform variables. +This causes many OpenGL errors and leads to incorrect rendering. +
+ +
+This test uses a single GLSL fragment shader which contains a GLSL 1.20
+array initializer statement, but it neglects to specify
+#version 120
at the top of the shader code.
+So, the shader does not compile and all that's rendered is plain white polygons.
+
+Also, the test tries to create a very large 3D texture that may exceed +the device driver's limit. +When this happens, the glTexImage3D call fails and all that's rendered is +a white box. +
+ + ++This is actually a DX11 test based on Autodesk's Showcase product. +As such, it won't run with Mesa. +
+ +