Bug 97351

Summary: DrawElementsBaseVertex with VBO ignores base vertex on Intel GMA 9xx in some cases
Product: Mesa Reporter: Ruslan Kabatsayev <b7.10110111>
Component: Drivers/DRI/i915Assignee: Ian Romanick <idr>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: imirkin
Version: git   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: Test case
Test case
candidate fix

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).
Comment 9 Ilia Mirkin 2016-08-19 00:28:44 UTC
Fix pushed:

commit 659dc10d32b5a2ca61d23f2ae43c9e241aff6a26
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Aug 17 17:12:09 2016 -0400

    vbo: add basevertex when looking up elements for vbo splitting

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.