| 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: | |
| Severity: | normal | ||
| Priority: | medium | CC: | imirkin |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Test case
Test case candidate fix |
||
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. 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.] (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. 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...
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? */ Also reproduces in "Software Rasterizer" driver (i.e. non-Gallium swr). 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. This does seem to work for me, also fixes the original test case (GTA Vice City in Wine). 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.
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.