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

[Marek Olšák]

Hi,

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
commit):
http://cgit.freedesktop.org/~mareko/mesa/log/?h=st-mesa-user-buf

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.

Marek


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.