|Summary:||DrawElementsBaseVertex with VBO ignores base vertex on Intel GMA 9xx in some cases|
|Product:||Mesa||Reporter:||Ruslan Kabatsayev <b7.10110111>|
|Component:||Drivers/DRI/i915||Assignee:||Ian Romanick <idr>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Ruslan Kabatsayev 2016-08-15 11:33:12 UTC
Created attachment 125791 [details] Test case The attached test case should show show a polygon-like object on the left side of its window in odd frames and some mess in the lower half of the window in even frames, with different backgrounds. The polygon is rendered with DrawElementsBaseVertex, while the mess is due to DrawElements with the same data, which is the same as setting baseVertex to 0. On Intel Atom N550 only background alternates, i.e. DrawElementsBaseVertex behaves as if it were always passed baseVertex==0. I couldn't reproduce this problem when I tried to just create a vertex buffer with 4 vertices and index buffer with 3 indices, so the test case contains somewhat larger datasets, put into separate files.
Comment 1 Ruslan Kabatsayev 2016-08-15 14:23:59 UTC
Also reproducible with Mesa 12.0-branchpoint-1757-g5d9b50e. Tested on Linux 3.19.0-64-generic from Ubuntu 14.04 LTS, Intel Atom N550 on EEE PC 1015PN.
Comment 2 Ilia Mirkin 2016-08-15 17:42:49 UTC
Which i915 driver are you using? Classic or gallium? (glxinfo should make that apparent) [I won't be able to help in either case, FYI, but it should be important to anyone debugging this.]
Comment 3 Ruslan Kabatsayev 2016-08-15 18:12:25 UTC
(In reply to Ilia Mirkin from comment #2) > Which i915 driver are you using? Classic or gallium? (glxinfo should make > that apparent) [I won't be able to help in either case, FYI, but it should > be important to anyone debugging this.] OpenGL renderer string: Mesa DRI Intel(R) Pineview M x86/MMX/SSE2.
Comment 4 Ruslan Kabatsayev 2016-08-17 09:49:20 UTC
Created attachment 125839 [details] Test case Here's a much simplified test case. I've found that minimum baseVertex value, for which the problem occurs (VERTEX_OFFSET in the test source) is 2998. If I set it to 2997, it works correctly. Strange values, seem pretty arbitrary...
Comment 5 Ruslan Kabatsayev 2016-08-17 12:20:41 UTC
It seems I know where the problem resides. 2997 is MAX_ARRAY_LOCK_SIZE-3. MAX_ARRAY_LOCK_SIZE is written (with addition of MAX_CLIPPED_VERTICES) to tnl->vb.Size used in _tnl_draw_prims() to get `max`. Then this function gets into "else if ((GLint)max_index + max_basevertex > max)" branch, which calls vbo_split_prims(), where we can see that basevertex isn't actually ever used: vbo_split.c:117: /* XXX max_basevertex is computed but not used, why? */
Comment 6 Ruslan Kabatsayev 2016-08-17 16:11:39 UTC
Also reproduces in "Software Rasterizer" driver (i.e. non-Gallium swr).
Comment 7 Ilia Mirkin 2016-08-17 17:23:38 UTC
Created attachment 125853 [details] [review] candidate fix This fixes the repro case for me on swrast. I wouldn't be surprised if there were additional issues though.
Comment 8 Ruslan Kabatsayev 2016-08-17 19:36:44 UTC
This does seem to work for me, also fixes the original test case (GTA Vice City in Wine).