The compiler has a lot of code to implement UBOs that uses UniformBlocks
intensively in multiples places. When we implemented SSBOs, which need
to go pretty much through the same process, we had two options:
1) Rework all this code (and other parts of the frontend that use this
array) to accomodate a second array of objects and have all the pieces
access/index into one or the other (or both) depending on the kind of
object we are manipulating or what the code is trying to achieve.
2) Simply merge SSBOs into UniformBlocks. This lets the compiler do all
the things it needs to do for SSBOs without significant changes to the
code. This is what we implemented, since it it was less invasive and it
would not increase the complexity of code that is already complex enough
as it is. It should also make maintenance easy, since as far the compiler
is involved, we don't really have to care if we are manipulating SSBOs or
UBOs, so fixes or changes to the code will apply naturally to both, which
is probably what we want most of the time.
However, based on recent discussions with Ilia and Curro this creates an
inconvenience for drivers that expect different index spaces for both kinds
of objects, which is probably the majority since in the end the GL API
defines both as separate entities. As it is now, drivers that want separate
index spaces for UBOs and SSBOs require to remap the indices, which can be
done, but is not nice.
This 2-patch series implements a solution for this that tries to keep
the compiler frontend untouched while providing backends with separate
index spaces. The idea is that we can have the compiler work with a
single list of blocks and do all the linking process like that.
No changes here. Then, after linking, we can create two separate arrays
for UBOs and SSBOs. Drivers that need a separate index space only need
to reference these arrays instead of the one that mixes both kinds.
I think this gives everyone what they need without major changes so
hopefully it is a good way to go for now, even if we still want to
do the bigger change in the future (not sure that we want to do that
though). Would this be sufficient?
Patch1: Renames {Num}UniformBlocks to {Num}BufferInterfaceBlocks. This is
more consistent with the current implementation.
Patch2: Adds separate UniformBlocks and ShaderStorageBlocks arrays.
Iago Toral Quiroga (2):
mesa: Rename {Num}UniformBlocks to {Num}BufferInterfaceBlocks
mesa: Add {Num}UniformBlocks and {Num}ShaderStorageBlocks to
gl_shader_program
src/glsl/link_uniform_initializers.cpp | 4 +-
src/glsl/link_uniforms.cpp | 22 +++----
src/glsl/linker.cpp | 79 +++++++++++++++++-------
src/glsl/lower_ubo_reference.cpp | 8 +--
src/glsl/standalone_scaffolding.cpp | 11 +++-
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 10 +--
src/mesa/main/mtypes.h | 12 +++-
src/mesa/main/shader_query.cpp | 4 +-
src/mesa/main/shaderapi.c | 4 +-
src/mesa/main/shaderobj.c | 4 +-
src/mesa/main/uniforms.c | 12 ++--
src/mesa/state_tracker/st_atom_constbuf.c | 4 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 +-
16 files changed, 117 insertions(+), 67 deletions(-)
--
1.9.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
