[Mesa-dev] [PATCH 00/21] Gallium: making user vertex buffers optional and other goodness
Christian König
deathsimple at vodafone.de
Thu Apr 12 01:26:34 PDT 2012
On 11.04.2012 17:38, Marek Olšák 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.
It looks like a step into the right direction to me, cause AFAIK we need
something similar for radeonsi as well, but I think you should fix (3)
before committing it.
As a side note, I really wonder why r600g doesn't support scaled/norm
integer formats with 32 bits per channel?
Well the hardware fetcher doesn't support converting from 32 integers to
floats, but you can always fetch them as integers and call INT_TO_FLT in
the fetch shader manually. Not much of an optimization, but at least a
quite low hanging fruit.
Christian.
>
> 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