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