[Mesa-dev] [PATCH 00/21] Gallium: making user vertex buffers optional and other goodness
Jose Fonseca
jfonseca at vmware.com
Sat Apr 14 01:03:12 PDT 2012
Hi Marek,
----- Original Message -----
> 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.
I've looked at the series a bit more closely, and it looks great to me.
> 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.
The new CAPS talk about DWORD alignment only. What about the alignment of doubles? Does GL or any hardware allow non-aligned doubles?
> 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.
Sounds a good plan to me.
Jose
>
> There is also a lot of refactoring code in r300g and r600g, but
> nothing significant.
>
> Please review & comment.
>
> Marek Olšák (21):
> cso: unreference saved vertex buffers when restoring
> cso: add set_index_buffer and draw_vbo passthrough functions
> gallium/util: use cso_draw_arrays in util_draw_vertex_buffer
> st/mesa: use cso_set_index_buffer and cso_draw_vbo
> u_vbuf: override set_index_buffer
> u_vbuf: override set_vertex_buffers
> u_vbuf: override create/bind/destroy_vertex_elements_state
> u_vbuf: override draw_vbo
> gallium: add user_ptr in pipe_resource
> u_vbuf: use user_ptr from pipe_resource
> u_vbuf: remove u_vbuf_resource
> gallium: add CAPs for vertex fetcher
> gallium drivers: report that user vertex buffers are supported
> u_vbuf: make use of the new CAPs to determine what to do
> u_vbuf: pull u_vbuf_draw_max_vertex_count into r300g
> r300g: don't share u_upload_mgr with u_vbuf, create its own
> r600g: don't share u_upload_mgr with u_vbuf, create its own
> i915g: report that all vertex formats are supported
> gallium: make user vertex buffers optional
> st/mesa: always expose ARB_half_float_vertex
> st/mesa: always expose ARB_ES2_compatibility
>
> src/gallium/auxiliary/cso_cache/cso_context.c | 84 ++++
> src/gallium/auxiliary/cso_cache/cso_context.h | 28 ++
> src/gallium/auxiliary/util/u_draw_quad.c | 9 +-
> src/gallium/auxiliary/util/u_vbuf.c | 480
> +++++++++++-----------
> src/gallium/auxiliary/util/u_vbuf.h | 99 +----
> src/gallium/drivers/i915/i915_resource_buffer.c | 1 +
> src/gallium/drivers/i915/i915_screen.c | 5 +-
> src/gallium/drivers/llvmpipe/lp_screen.c | 2 +
> src/gallium/drivers/llvmpipe/lp_texture.c | 1 +
> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 +
> src/gallium/drivers/nv50/nv50_screen.c | 2 +
> src/gallium/drivers/nvc0/nvc0_screen.c | 2 +
> src/gallium/drivers/nvfx/nvfx_buffer.c | 1 +
> src/gallium/drivers/nvfx/nvfx_screen.c | 2 +
> src/gallium/drivers/r300/r300_blit.c | 9 +-
> src/gallium/drivers/r300/r300_context.c | 18 +-
> src/gallium/drivers/r300/r300_context.h | 14 +-
> src/gallium/drivers/r300/r300_emit.c | 15 +-
> src/gallium/drivers/r300/r300_fs.c | 2 +-
> src/gallium/drivers/r300/r300_render.c | 105 ++++--
> src/gallium/drivers/r300/r300_render_translate.c | 6 +-
> src/gallium/drivers/r300/r300_screen.c | 11 +-
> src/gallium/drivers/r300/r300_screen_buffer.c | 54 ++--
> src/gallium/drivers/r300/r300_state.c | 48 +--
> src/gallium/drivers/r300/r300_state_derived.c | 6 +-
> src/gallium/drivers/r300/r300_texture.c | 16 +-
> src/gallium/drivers/r300/r300_texture_desc.c | 102 +++---
> src/gallium/drivers/r300/r300_transfer.c | 6 +-
> src/gallium/drivers/r600/evergreen_state.c | 10 +-
> src/gallium/drivers/r600/r600.h | 3 +-
> src/gallium/drivers/r600/r600_blit.c | 14 +-
> src/gallium/drivers/r600/r600_buffer.c | 58 ++--
> src/gallium/drivers/r600/r600_formats.h | 3 +-
> src/gallium/drivers/r600/r600_hw_context.c | 6 +-
> src/gallium/drivers/r600/r600_pipe.c | 22 +-
> src/gallium/drivers/r600/r600_pipe.h | 6 +-
> src/gallium/drivers/r600/r600_query.c | 4 +-
> src/gallium/drivers/r600/r600_state.c | 6 +-
> src/gallium/drivers/r600/r600_state_common.c | 41 +-
> src/gallium/drivers/r600/r600_texture.c | 28 +-
> src/gallium/drivers/r600/r600_translate.c | 2 +-
> src/gallium/drivers/softpipe/sp_screen.c | 2 +
> src/gallium/drivers/softpipe/sp_texture.c | 1 +
> src/gallium/drivers/svga/svga_resource_buffer.c | 1 +
> src/gallium/drivers/svga/svga_screen.c | 2 +
> src/gallium/include/pipe/p_defines.h | 6 +-
> src/gallium/include/pipe/p_state.h | 3 +
> src/mesa/state_tracker/st_context.c | 26 ++
> src/mesa/state_tracker/st_context.h | 3 +
> src/mesa/state_tracker/st_draw.c | 16 +-
> src/mesa/state_tracker/st_extensions.c | 8 +-
> 51 files changed, 764 insertions(+), 636 deletions(-)
>
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list