aboutsummaryrefslogtreecommitdiffstats
path: root/src/compiler/glsl/gl_nir_lower_buffers.c
Commit message (Collapse)AuthorAgeFilesLines
* glsl/nir: do not change an element index to have correct block nameAndrii Simiklit2020-01-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | When SSBO array is used with packed layout, both IR tree and as a result, NIR tree will be incorrect. In fact, the SSBO dereference indices won't match the array size in some cases like the following: "layout(packed, binding=1) buffer SSBO { vec4 a; } ssbo[3]; out vec4 color; void main() { color = ssbo[2].a; }" After linking the IR and then NIR will have an SSBO array definition with size 1 but dereference still will have index 2 and linked_shader->Program->sh.ShaderStorageBlocks will contain just SSBO with name "SSBO[2]" So this line should be removed at least as a workaround for now to avoid error like: Failed to find the block by name "SSBO[0]" Fixes: 810dde2a "glsl/nir: Add a pass to lower UBO and SSBO access" Signed-off-by: Andrii Simiklit <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* nir: add amul instructionRob Clark2019-10-181-1/+1
| | | | | | | | | | | | Used for address/offset calculation (ie. array derefs), where we can potentially use less than 32b for the multiply of array idx by element size. For backends that support `imul24`, this gives a lowering pass an easy way to find multiplies that potentially can be converted to `imul24`. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* glsl/nir: Lower buffers using Binding instead of NamesCaio Marcelo de Oliveira Filho2019-06-301-5/+28
| | | | | | | | When using ARB_gl_spirv, the block names are optional and the uniform blocks are referred using Bindings instead. Teach gl_nir_lower_buffers to handle those. Reviewed-by: Timothy Arceri <[email protected]>
* glsl/nir: Add a pass to lower UBO and SSBO accessJason Ekstrand2019-03-151-0/+300
Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>