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

[Brian Paul]

On Wed, Apr 11, 2012 at 9:38 AM, Marek Olšák <maraeo at gmail.com> wrote:
> Hi everyone,
>
> This series adds these optional features to st/mesa:
> - uploading user vertex buffers
> - translating unsupported vertex formats into floats
> - vertex data with unaligned buffer_offset, src_offset, or stride is transformed such that it's aligned
>
> These vertex formats are automatically translated into float if the driver doesn't expose them through is_format_supported(PIPE_BIND_VERTEX_BUFFER):
> - PIPE_FORMAT_*16_FLOAT
> - PIPE_FORMAT_*64_FLOAT
> - PIPE_FORMAT_*32_FIXED
> - PIPE_FORMAT_*32_UNORM
> - PIPE_FORMAT_*32_SNORM
> - PIPE_FORMAT_*32_USCALED
> - PIPE_FORMAT_*32_SSCALED
>
> This series doesn't deal with uploads of:
> - user index buffers
> - user constant buffers
>
> It's all done by moving the u_vbuf module out of the radeon drivers and into the Mesa state tracker. u_vbuf is installed into cso_context, where it overrides a few functions. The installation is done only when the driver doesn't support a certain feature (a vertex format or user buffers or has buffer alignment restrictions). That's pretty much it.
>
> There are new CAPs for vertex buffer alignment and, of course, user vertex buffers. I had to add "uint8_t *user_ptr" into pipe_resource, so that I could access the user buffer pointer in the state tracker.
>
> 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.
>
> There is also a lot of refactoring code in r300g and r600g, but nothing significant.
>
> Please review & comment.

I looked over the rest of the series and it looks good to me.

-Brian