With SSO, the GL_PROGRAM_INPUT and GL_PROGRAM_OUTPUT interfaces refer to
the first and last shader stage linked into a program. This may not be
the vertex and fragment shader stages.
So, subtracting VERT_ATTRIB_GENERIC0 and FRAG_RESULT_DATA0 is bogus.
We need to subtract VERT_ATTRIB_GENERIC0 for VS inputs,
FRAG_RESULT_DATA0 for FS outputs, and VARYING_SLOT_VAR0 for other cases.
Note that built-in variables get a location of -1.
Fixes 4 dEQP-GLES31.functional.program_interface_query tests:
- program_input.location.separable_fragment.var_explicit_location
- program_input.location.separable_fragment.var_array_explicit_location
- program_output.location.separable_vertex.var_array_explicit_location
- program_output.location.separable_vertex.var_array_explicit_location
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We were recording locations for all variables, even ones without an
explicit location set. Implement the rules from the spec, and record
-1 in the resource list accordngly. Make program_resource_location
stop doing math on negative values. Remove hacks that are no longer
necessary now that we've stopped doing that.
Fixes 4 dEQP-GLES31.functional.program_interface_query tests:
- program_input.location.separable_fragment.var
- program_input.location.separable_fragment.var_array
- program_output.location.separable_vertex.var_array
- program_output.location.separable_vertex.var_array
v2: Delete more code
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
A program will either have gl_VertexID or gl_VertexIDMESA (the lowered
zero-based version), not both. Just spoof it in the resource list so
the hacks are done in a single place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
System values are just built-in input variables that we've opted to
special-case out of convenience. We need to consider all inputs,
regardless of how we've classified them.
Unfortunately, there's one exception: we shouldn't add gl_BaseVertex
unless ARB_shader_draw_parameters is enabled, because it doesn't
actually exist in the language, and shouldn't be counted in the
GL_ACTIVE_RESOURCES query.
Fixes dEQP-GLES31.functional.program_interface_query.program_input.
resource_list.compute.empty, which expects gl_NumWorkGroups to appear
in the resource list.
v2: Delete more code
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This makes no sense. If the stage being considered is the vertex
shader, then we'll add inputs and system values appropriately.
If we're not considering the vertex shader, then we absolutely should
not do anything with it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
add_interface_variables() is supposed to add variables for the inputs of
the first shader stage linked into a program, and the outputs of the
last shader stage linked into a program.
From the ARB_program_interface_query specification:
"* PROGRAM_INPUT corresponds to the set of active input variables used by
the first shader stage of <program>. If <program> includes multiple
shader stages, input variables from any shader stage other than the
first will not be enumerated.
* PROGRAM_OUTPUT corresponds to the set of active output variables
(section 2.14.11) used by the last shader stage of <program>. If
<program> includes multiple shader stages, output variables from any
shader stage other than the last will not be enumerated."
Previously, we used build_stageref here, which walks over all linked
shaders in the program. This meant that internal varyings would be
visible. We don't actually need any of build_stageref's code: we
already explicitly skip packed varyings, handle modes, and the name
comparisons just do a fuzzy string comparison of name with itself.
Fixes two tests: dEQP-GLES31.functional.program_interface_query.
program_{input,output}.referenced_by.referenced_by_vertex_fragment.
These tests have a VS and FS linked together into a single program.
Both stages have an input called "shaderInput". But the FS input
should not be visible because it isn't the first stage.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This is a bitfield of which stages refer to a variable. It is not used
to mask off bits. In fact, it's used to contribute additional bits.
Rename it and tidy a bit of the logic.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
add_interface_variables is supposed to add variables from either the
first or last stage of a linked shader. But it has no way of knowing
the stage it's being asked to process, which makes it impossible to
produce correct stagerefs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
If the GL_ARB_shader_draw_parameters extension is enabled, we'll already
have a gl_BaseVertex variable. It will have var->how_declared set to
ir_var_declared_implicitly, and will appear in the program resource
list.
If not, we make one for internal use. We don't want it to be listed
in the program resource list, as the application won't be expecting
it. Marking it hidden will properly exclude it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
We occasionally generate variables internally that we want to exclude
from the program resource list, as applications won't be expecting them
to be present.
The next patch will make use of this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Note: This patch appears to violate older OpenGL and OpenGLES specs.
The OpenGLES GLSL 3.1 and OpenGL GLSL 4.3 specifications both remove
the requirement for the output and input centroid qualifiers to match.
The deqp
dEQP-GLES3.functional.shaders.linkage.varying.rules.differing_interpolation_2
test wants the newer OpenGLES 3.1 specification behavior, even for
OpenGLES 3.0. This patch simply removes the checking in all cases.
The OpenGLES 3.0 conformance test suite doesn't appear to require the
older ("must match") spec behavior.
For reference, here are the relavent spec citations:
The OpenGL 4.2 spec says: "the last active shader stage output
variables and fragment shader input variables of the same name must
match in type and qualification (other than out matching to in)"
The OpenGL 4.3 spec says: "interpolation qualification (e.g., flat)
and auxiliary qualification (e.g. centroid) may differ."
The OpenGLES GLSL 3.00.4 specification says: "The output of the
vertex shader and the input of the fragment shader form an
interface. For this interface, vertex shader output variables and
fragment shader input variables of the same name must match in type
and qualification (other than precision and out matching to in)."
The OpenGLES GLSL 3.10 Specification says: "interpolation
qualification (e.g., flat) and auxiliary qualification (e.g.
centroid) may differ"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92743
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=7819
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Just noticed this in passing.. gl_shader_stage already has tess so this
comment no longer applies.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Needed because not all the built-in variables are marked as system
values, so they still have the mode ir_var_auto. Right now it fixes
raising the warning when gl_GlobalInvocationID and
gl_LocalInvocationIndex are used.
v2: use is_gl_identifier instead of filtering for some names (Ilia
Mirkin)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Oddly, this did not affect the shader where I first noticed the pattern.
That particular shader doesn't get its if-statement converted to a bcsel
because there are two assignments in the else-statement. This led to me
submitting https://bugs.freedesktop.org/show_bug.cgi?id=94747.
shader-db results:
Sandy Bridge
total instructions in shared programs: 8467384 -> 8467069 (-0.00%)
instructions in affected programs: 36594 -> 36279 (-0.86%)
helped: 46
HURT: 0
total cycles in shared programs: 117573448 -> 117568518 (-0.00%)
cycles in affected programs: 339114 -> 334184 (-1.45%)
helped: 46
HURT: 0
Ivy Bridge / Haswell / Broadwell / Skylake:
total instructions in shared programs: 7774258 -> 7773999 (-0.00%)
instructions in affected programs: 30874 -> 30615 (-0.84%)
helped: 46
HURT: 0
total cycles in shared programs: 65739190 -> 65734530 (-0.01%)
cycles in affected programs: 180380 -> 175720 (-2.58%)
helped: 45
HURT: 1
No change on G45 or Ironlake.
I also tried these expressions, but none of them affected any shaders in
shader-db:
(('bcsel', a, 'a@bool', 'b@bool'), ('ior', a, b)),
(('bcsel', a, 'b@bool', False), ('iand', a, b)),
(('bcsel', a, 'b@bool', 'a@bool'), ('iand', a, b)),
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This enables in shader defined transform feedback mode even if the
only place xfb_stride is defined is on the global out.
We don't worry about xfb_buffer since Issue 22 c) in the spec says:
"If the shader has an "xfb_buffer" qualifier identifying a buffer,
but doesn't declare "xfb_offset" on anything associated with it,
what happens?
...
variables not qualified with "xfb_offset" are not captured, which
makes the associated "xfb_buffer" qualifier irrelevant."
Reviewed-by: Dave Airlie <airlied@redhat.com>
When we move to the next buffer we need to reset the stream
so that we don't generate an error message about streams not
matching.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This moves the check until after we have done the stride
calculation and applies it to the xfb_* qualifiers.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_enhanced_layous spec:
"It is a compile-time or link-time error to have any *xfb_offset*
that overflows *xfb_stride*, whether stated on declarations before
or after the *xfb_stride*, or in different compilation units.
...
When no *xfb_stride* is specified for a buffer, the stride of a
buffer will be the smallest needed to hold the variable placed at
the highest offset, including any required padding."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Here we use the built-in validation in
ast_layout_expression::process_qualifier_constant() to check for mismatching
global out strides on buffers in a single shader.
From the ARB_enhanced_layouts spec:
"While *xfb_stride* can be declared multiple times for the same buffer,
it is a compile-time or link-time error to have different values
specified for the stride for the same buffer."
For intrastage validation a new helper link_xfb_stride_layout_qualifiers()
is created. We also take this opportunity to make sure stride is at least
a multiple of 4, we will validate doubles at a later stage.
From the ARB_enhanced_layouts spec:
"If the buffer is capturing any double-typed outputs, the stride must
be a multiple of 8, otherwise it must be a multiple of 4, or a
compile-time or link-time error results."
Finally we update store_tfeedback_info() to apply the strides to
LinkedTransformFeedback and update the buffers bitmask to mark any global
buffers with a stride as active. For example a shader with:
layout (xfb_buffer = 0, xfb_offset = 0) out vec4 gs_fs;
layout (xfb_buffer = 1, xfb_stride = 64) out;
Is expected to have a buffer bound to both 0 and 1.
From the ARB_enhanced_layouts spec:
"A binding point requires a bound buffer object if and only if its
associated stride in the program object used for transform feedback
primitive capture is non-zero."
Reviewed-by: Dave Airlie <airlied@redhat.com>
This will be used in a following patch to implement interface
query support for TRANSFORM_FEEDBACK_BUFFER.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This allows us to print the correct binding point when not all
buffers declared in the shader are bound.
For example if we use a single buffer:
layout(xfb_buffer=2, offset=0) out vec4 v;
We now print '2' when the buffer is not bound rather than '0'.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This adds the initial infrastructure for enabling transform feedback
mode via in shader qualifiers and adds initial buffer support.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This function checks for any xfb_* qualifiers which will enable
transform feedback mode and cause any API defined xfb varyings
to be ignored.
It also counts the number of varyings that have a xfb_offset
qualifier and finally it calls the create_xfb_varying_names()
helper to generate the names of varyings to be caputured.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This will be used to get a count of the number of varying name
strings we are required to generate for use with the query api.
Reviewed-by: Dave Airlie <airlied@redhat.com>
When we have an interface block like:
layout (xfb_buffer = 0, xfb_offset = 0) out Block {
vec4 var1;
layout (xfb_stride = 32) vec4 var2;
vec4 var3;
};
We take into account the stride of var2 when calculating the offset
for var3.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_enhanced_layouts spec:
"The *xfb_stride* qualifier specifies how many bytes are consumed
by each captured vertex. It applies to the transform feedback
buffer for that declaration, whether it is inherited or explicitly
declared. It can be applied to variables, blocks, block members,
or just the qualifier out. If the buffer is capturing any
double-typed outputs, the stride must be a multiple of 8, otherwise
it must be a multiple of 4, or a compile-time or link-time error
results.
...
The resulting stride (implicit or explicit) must be less than or
equal to the implementation-dependent constant
gl_MaxTransformFeedbackInterleavedComponents."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Also copies the qualifier values to GLSL IR.
From the ARB_enhanced_layouts spec:
"The *xfb_buffer* qualifier can be applied to the qualifier out,
to output variables, to output blocks, and to output block
members. Shaders in the transform feedback capturing mode have
an initial global default of
layout(xfb_buffer = 0) out;
This default can be changed by declaring a different buffer with
xfb_buffer on the interface qualifier out. This is the only way
the global default can be changed. When a variable or output block
is declared without an xfb_buffer qualifier, it inherits the global
default buffer. When a variable or output block is declared with an
xfb_buffer qualifier, it has that declared buffer. All members of a
block inherit the block's buffer. A member is allowed to declare
an xfb_buffer, but it must match the buffer inherited from its
block, or a compile-time error results.
The *xfb_buffer* qualifier follows the same conventions, behavior,
defaults, and inheritance rules as the qualifier stream, and the
examples for stream apply here as well. This includes a block's
inheritance of the current global default buffer, a block member's
inheritance of the block's buffer, and the requirement that any
*xfb_buffer* declared on a block member must match the buffer
inherited from the block.
...
It is a compile-time error to specify an *xfb_buffer* that is
greater than the implementation-dependent constant
gl_MaxTransformFeedbackBuffers."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Since any of the xfb_* qualifiers trigger the shader to be in
transform feedback mode we need an extra field to track if
the xfb_buffer on interface members was set explicitly since
xfb_buffer will always have a default value.
Reviewed-by: Dave Airlie <airlied@redhat.com>
These will be used to hold qualifier values for interface and
struct members.
Support is added to the struct/interface constructors to copy these
fields upon creation.
We also update record_compare() to ensure we don't reuse a glsl_type
with the wrong xfb_* qualifier values.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This adds validation for all qualifiers as allowed by the
table in Section 4.4 (Layout Qualifiers) of the GLSL 4.5 spec.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Kenneth Graunke