Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 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> |
| 12 | This page lists known issues with |
| 13 | <a href="http://www.spec.org/gwpg/gpc.static/vp11info.html" target="_main">SPEC Viewperf 11</a> |
| 14 | when running on Mesa-based drivers. |
| 15 | </p> |
| 16 | |
| 17 | <p> |
| 18 | The Viewperf data sets are basically GL API traces that are recorded from |
| 19 | CAD applications, then replayed in the Viewperf framework. |
| 20 | </p> |
| 21 | |
| 22 | <p> |
| 23 | The primary problem with these traces is they blindly use features and |
| 24 | OpenGL extensions that were supported by the OpenGL driver when the trace |
| 25 | was recorded, |
| 26 | but there's no checks to see if those features are supported by the driver |
| 27 | when playing back the traces with Viewperf. |
| 28 | </p> |
| 29 | |
| 30 | <p> |
| 31 | These issues have been reported to the SPEC organization in the hope that |
| 32 | they'll be fixed in the future. |
| 33 | </p> |
| 34 | |
Brian Paul | 0615eb8 | 2012-04-19 14:38:45 -0600 | [diff] [blame] | 35 | <p> |
| 36 | Some of the Viewperf tests use a lot of memory. |
| 37 | At least 2GB of RAM is recommended. |
| 38 | </p> |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 39 | |
| 40 | |
Brian Paul | 9c0d782 | 2011-11-09 13:32:18 -0700 | [diff] [blame] | 41 | <h2>Catia-03 test 2</h2> |
| 42 | |
| 43 | <p> |
| 44 | This test creates over 38000 vertex buffer objects. On some systems |
| 45 | this can exceed the maximum number of buffer allocations. Mesa |
| 46 | generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf |
| 47 | does no error checking and continues. When this happens, some drawing |
| 48 | commands become no-ops. This can also eventually lead to a segfault |
| 49 | either in Viewperf or the Mesa driver. |
| 50 | </p> |
| 51 | |
| 52 | |
| 53 | |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 54 | <h2>Catia-03 tests 3, 4, 8</h2> |
| 55 | |
| 56 | <p> |
| 57 | These tests use features of the |
| 58 | <a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt" |
| 59 | target="_main"> |
| 60 | GL_NV_fragment_program2</a> and |
| 61 | <a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt" |
| 62 | target="_main"> |
| 63 | GL_NV_vertex_program3</a> extensions without checking if the driver supports |
| 64 | them. |
| 65 | </p> |
| 66 | <p> |
| 67 | When Mesa tries to compile the vertex/fragment programs it generates errors |
| 68 | (which Viewperf ignores). |
| 69 | Subsequent drawing calls become no-ops and the rendering is incorrect. |
| 70 | </p> |
| 71 | |
| 72 | |
| 73 | |
Brian Paul | 0fd4165 | 2012-04-11 11:53:33 -0600 | [diff] [blame] | 74 | <h2>sw-02 tests 1, 2, 4, 6</h2> |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 75 | |
| 76 | <p> |
| 77 | These tests depend on the |
| 78 | <a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt" |
| 79 | target="_main">GL_NV_primitive_restart</a> extension. |
| 80 | </p> |
| 81 | |
| 82 | <p> |
| 83 | If the Mesa driver doesn't support this extension the rendering will |
| 84 | be incorrect and the test will fail. |
| 85 | </p> |
| 86 | |
Brian Paul | a0c380a | 2012-05-01 15:49:31 -0600 | [diff] [blame^] | 87 | <p> |
| 88 | Also, the color of the line drawings in test 2 seem to appear in a random |
| 89 | color. This is probably due to some uninitialized state somewhere. |
| 90 | </p> |
| 91 | |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 92 | |
Brian Paul | 0fd4165 | 2012-04-11 11:53:33 -0600 | [diff] [blame] | 93 | |
| 94 | <h2>sw-02 test 6</h2> |
| 95 | |
| 96 | <p> |
| 97 | The lines drawn in this test appear in a random color. |
| 98 | That's because texture mapping is enabled when the lines are drawn, but no |
| 99 | texture image is defined (glTexImage2D() is called with pixels=NULL). |
| 100 | Since GL says the contents of the texture image are undefined in that |
| 101 | situation, we get a random color. |
| 102 | </p> |
| 103 | |
| 104 | |
| 105 | |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 106 | <h2>Lightwave-01 test 3</h2> |
| 107 | |
| 108 | <p> |
| 109 | This test uses a number of mipmapped textures, but the textures are |
| 110 | incomplete because the last/smallest mipmap level (1 x 1 pixel) is |
| 111 | never specified. |
| 112 | </p> |
| 113 | |
| 114 | <p> |
| 115 | A trace captured with |
| 116 | <a href="https://github.com/apitrace/apitrace" target="_main">API trace</a> |
| 117 | shows this sequences of calls like this: |
| 118 | |
| 119 | <pre> |
| 120 | 2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) |
| 121 | 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)) |
| 122 | 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)) |
| 123 | 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)) |
| 124 | [...] |
| 125 | 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)) |
| 126 | 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)) |
| 127 | 2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) |
| 128 | 2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) |
| 129 | 2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) |
| 130 | 2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) |
| 131 | </pre> |
| 132 | |
| 133 | <p> |
| 134 | Note that one would expect call 2514 to be glTexImage(level=9, width=1, |
| 135 | height=1) but it's not there. |
| 136 | </p> |
| 137 | |
| 138 | <p> |
| 139 | The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's |
| 140 | GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. |
| 141 | </p> |
| 142 | |
| 143 | <p> |
| 144 | Later, these incomplete textures are bound before drawing calls. |
| 145 | According to the GL specification, if a fragment program or fragment shader |
| 146 | is being used, the sampler should return (0,0,0,1) ("black") when sampling |
| 147 | from an incomplete texture. |
| 148 | This is what Mesa does and the resulting rendering is darker than it should |
| 149 | be. |
| 150 | </p> |
| 151 | |
| 152 | <p> |
| 153 | It appears that NVIDIA's driver (and possibly AMD's driver) detects this case |
| 154 | and returns (1,1,1,1) (white) which causes the rendering to appear brighter |
| 155 | and match the reference image (however, AMD's rendering is <em>much</em> |
| 156 | brighter than NVIDIA's). |
| 157 | </p> |
| 158 | |
| 159 | <p> |
| 160 | If the fallback texture created in _mesa_get_fallback_texture() is |
| 161 | initialized to be full white instead of full black the rendering appears |
| 162 | correct. |
| 163 | However, we have no plans to implement this work-around in Mesa. |
Brian Paul | 286e50a | 2012-04-13 14:31:16 -0600 | [diff] [blame] | 164 | </p> |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 165 | |
Brian Paul | 286e50a | 2012-04-13 14:31:16 -0600 | [diff] [blame] | 166 | |
| 167 | <h2>Maya-03 test 2</h2> |
| 168 | |
| 169 | <p> |
| 170 | This test makes some unusual calls to glRotate. For example: |
| 171 | </p> |
| 172 | <pre> |
| 173 | glRotate(50, 50, 50, 1); |
| 174 | glRotate(100, 100, 100, 1); |
| 175 | glRotate(52, 52, 52, 1); |
| 176 | </pre> |
| 177 | <p> |
| 178 | These unusual values lead to invalid modelview matrices. |
| 179 | For example, the last glRotate command above produces this matrix with Mesa: |
| 180 | <pre> |
| 181 | 1.08536e+24 2.55321e-23 -0.000160389 0 |
| 182 | 5.96937e-25 1.08536e+24 103408 0 |
| 183 | 103408 -0.000160389 1.74755e+09 0 |
| 184 | 0 0 0 nan |
| 185 | </pre> |
| 186 | and with NVIDIA's OpenGL: |
| 187 | <pre> |
| 188 | 1.4013e-45 0 -nan 0 |
| 189 | 0 1.4013e-45 1.4013e-45 0 |
| 190 | 1.4013e-45 -nan 1.4013e-45 0 |
| 191 | 0 0 0 1.4013e-45 |
| 192 | </pre> |
| 193 | <p> |
| 194 | This causes the object in question to be drawn in a strange orientation |
| 195 | and with a semi-random color (between white and black) since GL_FOG is enabled. |
Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 196 | </p> |
| 197 | |
| 198 | |
| 199 | </BODY> |
| 200 | </HTML> |