| 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 | |
| 35 | |
| 36 | |
| Brian Paul | 9c0d782 | 2011-11-09 13:32:18 -0700 | [diff] [blame^] | 37 | <h2>Catia-03 test 2</h2> |
| 38 | |
| 39 | <p> |
| 40 | This test creates over 38000 vertex buffer objects. On some systems |
| 41 | this can exceed the maximum number of buffer allocations. Mesa |
| 42 | generates GL_OUT_OF_MEMORY errors in this situation, but Viewperf |
| 43 | does no error checking and continues. When this happens, some drawing |
| 44 | commands become no-ops. This can also eventually lead to a segfault |
| 45 | either in Viewperf or the Mesa driver. |
| 46 | </p> |
| 47 | |
| 48 | |
| 49 | |
| Brian Paul | c60eb63 | 2011-10-20 15:13:17 -0600 | [diff] [blame] | 50 | <h2>Catia-03 tests 3, 4, 8</h2> |
| 51 | |
| 52 | <p> |
| 53 | These tests use features of the |
| 54 | <a href="http://www.opengl.org/registry/specs/NV/fragment_program2.txt" |
| 55 | target="_main"> |
| 56 | GL_NV_fragment_program2</a> and |
| 57 | <a href="http://www.opengl.org/registry/specs/NV/vertex_program3.txt" |
| 58 | target="_main"> |
| 59 | GL_NV_vertex_program3</a> extensions without checking if the driver supports |
| 60 | them. |
| 61 | </p> |
| 62 | <p> |
| 63 | When Mesa tries to compile the vertex/fragment programs it generates errors |
| 64 | (which Viewperf ignores). |
| 65 | Subsequent drawing calls become no-ops and the rendering is incorrect. |
| 66 | </p> |
| 67 | |
| 68 | |
| 69 | |
| 70 | <h2>sw-02 tests 1, 2, 4</h2> |
| 71 | |
| 72 | <p> |
| 73 | These tests depend on the |
| 74 | <a href="http://www.opengl.org/registry/specs/NV/primitive_restart.txt" |
| 75 | target="_main">GL_NV_primitive_restart</a> extension. |
| 76 | </p> |
| 77 | |
| 78 | <p> |
| 79 | If the Mesa driver doesn't support this extension the rendering will |
| 80 | be incorrect and the test will fail. |
| 81 | </p> |
| 82 | |
| 83 | |
| 84 | <h2>Lightwave-01 test 3</h2> |
| 85 | |
| 86 | <p> |
| 87 | This test uses a number of mipmapped textures, but the textures are |
| 88 | incomplete because the last/smallest mipmap level (1 x 1 pixel) is |
| 89 | never specified. |
| 90 | </p> |
| 91 | |
| 92 | <p> |
| 93 | A trace captured with |
| 94 | <a href="https://github.com/apitrace/apitrace" target="_main">API trace</a> |
| 95 | shows this sequences of calls like this: |
| 96 | |
| 97 | <pre> |
| 98 | 2504 glBindTexture(target = GL_TEXTURE_2D, texture = 55) |
| 99 | 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)) |
| 100 | 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)) |
| 101 | 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)) |
| 102 | [...] |
| 103 | 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)) |
| 104 | 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)) |
| 105 | 2514 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR) |
| 106 | 2515 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_REPEAT) |
| 107 | 2516 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_REPEAT) |
| 108 | 2517 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) |
| 109 | </pre> |
| 110 | |
| 111 | <p> |
| 112 | Note that one would expect call 2514 to be glTexImage(level=9, width=1, |
| 113 | height=1) but it's not there. |
| 114 | </p> |
| 115 | |
| 116 | <p> |
| 117 | The minification filter is GL_LINEAR_MIPMAP_LINEAR and the texture's |
| 118 | GL_TEXTURE_MAX_LEVEL is 1000 (the default) so a full mipmap is expected. |
| 119 | </p> |
| 120 | |
| 121 | <p> |
| 122 | Later, these incomplete textures are bound before drawing calls. |
| 123 | According to the GL specification, if a fragment program or fragment shader |
| 124 | is being used, the sampler should return (0,0,0,1) ("black") when sampling |
| 125 | from an incomplete texture. |
| 126 | This is what Mesa does and the resulting rendering is darker than it should |
| 127 | be. |
| 128 | </p> |
| 129 | |
| 130 | <p> |
| 131 | It appears that NVIDIA's driver (and possibly AMD's driver) detects this case |
| 132 | and returns (1,1,1,1) (white) which causes the rendering to appear brighter |
| 133 | and match the reference image (however, AMD's rendering is <em>much</em> |
| 134 | brighter than NVIDIA's). |
| 135 | </p> |
| 136 | |
| 137 | <p> |
| 138 | If the fallback texture created in _mesa_get_fallback_texture() is |
| 139 | initialized to be full white instead of full black the rendering appears |
| 140 | correct. |
| 141 | However, we have no plans to implement this work-around in Mesa. |
| 142 | |
| 143 | </p> |
| 144 | |
| 145 | |
| 146 | </BODY> |
| 147 | </HTML> |