Here we also make use of the UseSTD430AsDefaultPacking constant
and call the new get_internal_ifc_packing() helper.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
From page 140 (page 147 of the PDF) of the GLSL ES 3.10 v.4 spec:
" 9.2 Matching of Qualifiers
The following tables summarize the requirements for matching of
qualifiers. It applies whenever there are two or more matching
variables in a shader interface.
Notes:
1. Yes means the qualifiers must match.
...
9.2.1 Linked Shaders
| Qualifier | Qualifier | in/out | Default | uniform | buffer|
| Class | | | Uniforms | Block | Block |
...
| Layout | binding | N/A | Yes | Yes | Yes |"
From page 93 (page 110 of the PDF) of the GL 4.2 (Core Profile) spec:
" 2.11.7 Uniform Variables
...
Uniform Blocks
...
When a named uniform block is declared by multiple shaders in a
program, it must be declared identically in each shader. The
uniforms within the block must be declared with the same names and
types, and in the same order. If a program contains multiple
shaders with different declarations for the same named uniform
block differs between shader, the program will fail to link."
From page 129 (page 150 of the PDF) of the GL 4.3 (Core Profile) spec:
" 7.8 Shader Buffer Variables and Shader Storage Blocks
...
When a named shader storage block is declared by multiple shaders
in a program, it must be declared identically in each shader. The
buffer variables within the block must be declared with the same
names, types, qualification, and declaration order. If a program
contains multiple shaders with different declarations for the same
named shader storage block, the program will fail to link."
Therefore, if the binding qualifier differs between two linked Uniform
or Shader Storage Blocks of the same name, a link error should happen.
This patch will make that a link error will be reported on a program
like this:
"# VS
layout(binding = 1) Block {
vec4 color;
} uni_block1;
...
# FS
layout(binding = 2) Block {
vec4 color;
} uni_block2;
..."
Signed-off-by: Andres Gomez <agomez@igalia.com>
Cc: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
If an unsized declared array is not the last in an SSBO
and an implicit size can not be defined on linking time,
the linker should raise an error instead of reaching
an assertion on GL.
This reverts part of commit 3da08e1664
getting back to the behavior of commit 5b2675093e
The original patch was correct for GLES that should produce
a compile-time error but the linker error is still necessary
in desktop GL.
Fixes the following piglit tests:
tests/spec/arb_shader_storage_buffer_object/non_integral_size_array_member.shader_test
tests/spec/arb_shader_storage_buffer_object/unsized_array_member.shader_test
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
One for the array parts and one for the leaf members. This will
simplify later changes.
The indentation is wonkey after this patch. This was done to make it
more obvious that the function is just getting split. The next patch
will fix the indentation.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It looks like I added this version as a short-hand for users that didn't
need the fuller version. I don't think there's any real utility in
that. I'm not sure what my thinking was there. Maybe if those users
overloaded the recursion function could just call the compact version to
avoid passing some parameters? None of the users do that.
Either way, having this extra overload is not useful. Delete it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.
Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values
I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
So far we have been checking that interface block definitions had matching
matrix layouts by comparing the definitions of their fields, however, this
does not cover the case where the interface blocks are defined with
mismatching matrix layouts but don't define any field with a matrix type.
In this case Mesa will not fail to link because none of the fields will
inherit the mismatching layout qualifier.
This patch fixes the problem in the same way we fixed it for packing layout
information: we add the the layout information to the interface type and then
we check it matches during the uniform block linking process.
v2: Fix unit tests so they pass the new parameter to
glsl_type::get_interface_instance()
Fixes:
dEQP-GLES31.functional.shaders.linkage.uniform.block.layout_qualifier_mismatch_3
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98245
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
After the changes in comit 5b2675093e, we moved this check to the
linker, but the spec expects this to be checked at compile-time. There are
dEQP tests that expect an error at compile time and the spec seems to confirm
that expectation:
"Except for the last declared member of a shader storage block (section 4.3.9
“Interface Blocks”), the size of an array must be declared (explicitly sized)
before it is indexed with anything other than an integral constant expression.
The size of any array must be declared before passing it as an argument to a
function. Violation of any of these rules result in compile-time errors. It
is legal to declare an array without a size (unsized) and then later
redeclare the same name as an array of the same type and specify a size, or
index it only with integral constant expressions (implicitly sized)."
Commit 5b2675093e tries to take care of the case where we have implicitly
sized arrays in SSBOs and it does so by checking the max_array_access field
in ir_variable during linking. In this patch we change the approach: we look
for indirect access on SSBO arrays, and when we find one, we emit a
compile-time error if the accessed member is not the last in the SSBO
definition.
There is a corner case that the specs do not address directly though and that
dEQP checks for: the case of an unsized array in an SSBO definition that is
not defined last but is never used in the shader code either. The following
dEQP tests expect a compile-time error in this scenario:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader
However, since the unsized array is never used it is never indexed with a
non-constant expression, so by the spec quotation above, it should be valid and
the tests are probably incorrect.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
There are two distinctly different uses of this struct. The first
is to store GL shader objects. The second is to store information
about a shader stage thats been linked.
The two uses actually share few fields and there is clearly confusion
about their use. For example the linked shaders map one to one with
a program so can simply be destroyed along with the program. However
previously we were calling reference counting on the linked shaders.
We were also creating linked shaders with a name even though it
is always 0 and called the driver version of the _mesa_new_shader()
function unnecessarily for GL shader objects.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Although the glsl_types.h stores this in a bitfield,
we should hide that from everyone else. Hide the cast
in an accessor method and use the enum everywhere.
This makes things a bit nicer in gdb, and improves type
safety.
v2: fix a few pieces of interface I missed that caused some
piglit regressions.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The current code disallows unsized arrays except at the end of
an SSBO but it is a bit overzealous in doing so.
struct a {
int b[];
int f[4];
};
is valid as long as b is implicitly sized within the shader,
i.e. it is accessed only by integer indices.
I've submitted some piglit tests to test for this.
This also has no regressions on piglit on my Haswell.
This fixes:
GL45-CTS.shader_storage_buffer_object.basic-syntax
GL45-CTS.shader_storage_buffer_object.basic-syntaxSSO
This patch moves a chunk of the linker code down, so
that we don't link the uniform blocks until after we've
merged all the variables. The logic went something like:
Removing the checks for last ssbo member unsized from
the compiler and into the linker, meant doing the check
in the link_uniform_blocks code. However to do that the
array sizing had to happen first, so we knew that the
only unsized arrays were in the last block. But array
sizing required the variable to be merged, otherwise
you'd get two different array sizes in different
version of two variables, and one would get lost
when merged. So the solution was to move array sizing
up, after variable merging, but before uniform block
visiting.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With this change we create the UBO and SSBO arrays separately from the
beginning rather than putting them into a combined array and splitting
it apart later.
A bug is with UBO and SSBO stage reference querying is also fixed as
we now use the block index to lookup the references in the separate arrays
not the combined buffer block array.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
