[Bug 32768] New: VBO rendering using glDrawArrays causes program termination and "cs IB too big" message

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32768

           Summary: VBO rendering using glDrawArrays causes program
                    termination and "cs IB too big" message
           Product: xorg
           Version: 7.2
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: Driver/Radeon
        AssignedTo: xorg-driver-ati at lists.x.org
        ReportedBy: rcxslinger at gmail.com
         QAContact: xorg-team at lists.x.org


glDrawArrays can be used to render primitives stored inside a vbo. It takes
three parameters: "mode", "first" and "count". It has worked correctly with the
(free) ATI Radeon driver until a recent switch to Mesa 7.9. Now, when rendering
a large 3d model (count>31658) with an offset (start>0) in a vbo, the program
gets terminated with the following output on stderror:

"drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
See dmesg for more info."

And dmesg:

"[...]
[drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16386
[drm:r600_cs_legacy] *ERROR* Failed to initialize parser !
[...]"

Which is followed by several lines about "name:???? freeing invalid memtype
??????-????????" for the application ("freeing invalid memtype" gets printed on
earlier versions too, so it is probably not related).


My graphics card is an "hd 4670 AGP", cpu is i686, and so far I've noticed the
problem on both archlinux (using the official repos) and debian gnu/linux (by
installing libgl1-mesa-dri from experimental), and I can reproduce the bug
reliably by running any application that uses VBO and glDrawArrays to render a
large enough model (with an offset).

However, it does not occur when glDrawArrays is used for rendering array data
sent directly from client (from ram instead of uploaded into a vbo in video
memory). And it does not occur with the intel drivers, indicating that the bug
may be in the radeon drivers (but not causing any problems until the switch to
mesa 7.8).

It does occur with the mesa and radeon drivers from git (at 2010/12/25). And it
does not matter if kms (dri2) is enabled or not. It is possible that other
means of rendering primitives from a VBO with an offset can cause this problem
too (although I have not experimented with other means of rendering).

Note that the problem does not occur when the "start" parameter of glDrawArrays
is set to 0, or when "count" is 31658 or lower.



The easiest way of reproducing the bug is to take any simple vbo example/demo
(that renders enough primitives) and modify it to not draw the first few
primitives (such as triangles). For example:

http://nehe.gamedev.net/data/lessons/linuxsdl/lesson45.tar.gz

Gets this problem if changing line 269 into:
"glDrawArrays( GL_TRIANGLES, 3, g_pMesh->m_nVertexCount-3);"
(which will render all triangles except for the first one)

Again, note that with "start" left at 0 (which is the original case in the
example code) or "count" is changed to 31658 or lower, this problem does not
occur. Also, by uncommenting line 36 ("#define NO_VBOS"), the program will use
glDrawArrays to send data directly (instead of using a vbo) which will also
work as it should.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.