[Mesa-dev] [PATCH 00/21] Gallium: making user vertex buffers optional and other goodness

Marek Olšák maraeo at gmail.com
Thu Apr 19 15:04:51 PDT 2012


I plan to commit this series this weekend. I've made minor
improvements to u_vbuf and addressed all concerns, and I have tested
r300g and r600g, and made sure that softpipe and llvmpipe don't use
this code. Here are the updated patches (starting with the cso

What's missing:

1) Some drivers should handle PIPE_BIND_VERTEX_BUFFER in
is_format_supported and the new CAPs too. I can't do it, because I
don't know what the drivers are capable of.

2) The radeonsi driver hasn't been adapted yet. I don't have LLVM 3.1
at the moment, therefore I can't even compile the driver. I'll try to
take look at it this weekend unless someone else beats me to it.


On Wed, Apr 11, 2012 at 5:38 PM, Marek Olšák <maraeo at gmail.com> wrote:
> A couple of problems may arise with this:
> 1) r300g and r600g rely on what u_vbuf does, so other state trackers should either use u_vbuf too or be very careful about how they setup vertex buffers and vertex elements. Not every combination of states works and u_vbuf is good at not letting through what doesn't.
> 2) Drivers should properly handle PIPE_BIND_VERTEX_BUFFER in is_format_supported.
> 3) u_vbuf always and unconditionally uploads user vertex buffers if it's active. For example, if you only don't support PIPE_FORMAT_R64G64B64A64_FLOAT as a vertex format, but otherwise support user vertex buffers, then u_vbuf gets installed into cso_context and takes control. Drivers using the Draw module should expose all vertex formats, the user-vertex-buffer CAP, and not expose the buffer-alignment-restriction CAPs in order to avoid u_vbuf kicking in.
> 4) Drivers should not crash when receiving NULL vertex buffers via set_vertex_buffers. Such buffer are always unused by the vertex element state. The thing is one of the codepaths in u_vbuf is using the translate module, which usually takes a new vertex buffer slot. If you receive this in set_vertex_buffers: count=4, buffers={NULL, NULL, NULL, buffer}, it means the last buffer probably comes from translate and the other 3 were originally user buffers, which u_vbuf never lets through, so they end up being NULL.
> (2) must be fixed in some drivers, (3) can be fixed in u_vbuf if needed. I prefer (4) to be fixed in drivers.

More information about the mesa-dev mailing list