This patch adds two new fields to the gl_transform_feedback_info
struct:
- BufferStride records the total number of components (per vertex)
that transform feedback is being instructed to store in each buffer.
- Outputs[i].DstOffset records the offset within the interleaved
structure of each transform feedback output.
These values are needed by the i965 gen6 and r600g back-ends, so it
seems better to have the linker provide them rather than force each
back-end to compute them independently.
Also, DstOffset helps pave the way for supporting
ARB_transform_feedback3, which allows the transform feedback output to
contain holes between attributes by specifying
gl_SkipComponents{1,2,3,4} as the varying name.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
This is only temporary until a better solution is available.
v2: print warnings and add gallium CAPs
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is also done in ir_to_mesa and st_glsl_to_tgsi, but that code
will be removed soon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch modifies the GLSL linker to assign additional slots for
varying variables used by transform feedback, and record the varying
slots used by transform feedback for use by the driver back-end.
This required modifying assign_varying_locations() so that it assigns
a varying location if either (a) the varying is used by the next stage
of the GL pipeline, or (b) the varying is required by transform
feedback. In order to avoid duplicating the code to assign a single
varying location, I moved it into its own function,
assign_varying_location().
In addition, to support transform feedback in the case where there is
no fragment shader, it is now possible to call
assign_varying_locations() with a consumer of NULL.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Tested-by: Marek Olšák <maraeo@gmail.com>
Fixes piglit's bindfragdata-link-error.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Switch all of the code in ir_to_mesa, st_glsl_to_tgsi, glUniform*,
glGetUniform, glGetUniformLocation, and glGetActiveUniforms to use the
gl_uniform_storage structures in the gl_shader_program.
A couple of notes:
* Like most rewrite-the-world patches, this should be reviewed by
applying the patch and examining the modified functions.
* This leaves a lot of dead code around in linker.cpp and
uniform_query.cpp. This will be deleted in the next patches.
v2: Update the comment block (previously a FINISHME) in _mesa_uniform
about generating GL_INVALID_VALUE when an out-of-range sampler index
is specified.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
This requires tracking a couple extra fields in ir_variable:
* A flag to indicate that a variable had an initializer.
* For non-const variables, a field to track the constant value of the
variable's initializer.
For variables non-constant initalizers, ir_variable::has_initializer
will be true, but ir_variable::constant_initializer will be NULL. The
linker can use the values of these fields to check adherence to the
GLSL 4.20 rules for shared global variables:
"If a shared global has multiple initializers, the initializers
must all be constant expressions, and they must all have the same
value. Otherwise, a link error will result. (A shared global
having only one initializer does not require that initializer to
be a constant expression.)"
Previous to 4.20 the GLSL spec simply said that initializers must have
the same value. In this case of non-constant initializers, this was
impossible to determine. As a result, no vendor actually implemented
that behavior. The 4.20 behavior matches the behavior of NVIDIA's
shipping implementations.
NOTE: This is candidate for the 7.11 branch. This patch also needs
the preceding patch "glsl: Refactor generate_ARB_draw_buffers_variables
to use add_builtin_constant"
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34687
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
I suspect the indentation got messed up during a code merge.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Consider the following vertex shader and fragment shader:
// vertex shader
varying vec4 v;
uniform vec4 u;
void main() { gl_Position = vec4(0.0); v = u; }
// fragment shader
void main() { gl_FragColor = vec4(0.0); }
Since the fragment shader does not use 'v', it is demoted from a
varying to a simple global variable. Once that happens, the
assignment to 'v' is useless, and it should be removed. In addition,
'u' is no longer active, and it should also be removed.
Performing extra dead code elimination after demoting shader inputs
and outputs takes care of this. This elimination must occur before
assigning uniform locations, or the declaration of 'u' cannot be
removed.
This change *breaks* the piglit test getuniform-01, but that test is
already incorrect. The test uses a vertex shader that assigns to a
user-defined varying, but it has no fragment shader. Since Mesa does
not support ARB_separate_shader_objects (we only support the EXT
version), the linker correctly eliminates the user-defined varying.
The cascading effect is that the uniform queried by the C code of the
test is also (correctly) eliminated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41980
Tested-by: Brian Paul <brianp@vmware.com>
Cc: Bryan Cain <bryancain3@gmail.com>
Cc: Vinson Lee <vlee@vmware.com>
Cc: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Setting this flag prevents declarations of uniforms from being removed
from the IR. Since the IR is directly used by several API functions
that query uniforms in shaders, uniform declarations cannot be removed
after the locations have been set. However, it should still be safe
to reorder the declarations (this is not tested).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41980
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Bryan Cain <bryancain3@gmail.com>
Cc: Vinson Lee <vlee@vmware.com>
Cc: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
On converting fixed function programs to generate GLSL, the linker
became cranky that we were trying to make something that wasn't a
linked vertex+fragment program. Given that the Mesa GLES2 drivers
also support desktop GL with EXT_sso, just telling the linker to shut
up seems like the easiest solution.
The symbol table in the linked shaders may contain references to
variables that were removed (e.g., unused uniforms). Since it may
contain junk, there is no possible valid use. Delete it and set the
pointer to NULL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
GLSL 1.30 requires us to use gl_ClipDistance for clipping if the
vertex shader contains a static write to it, and otherwise use
user-defined clipping planes. Since the driver needs to behave
differently in these two cases, we need a flag to record whether the
shader has written to gl_ClipDistance.
The new flag is called UsesClipDistance. We initially store it in
gl_shader_program (since that is the data structure that is available
when we check to see whethe gl_ClipDistance was written to), and we
later copy it to a flag with the same name in gl_vertex_program, since
that is a more convenient place for the driver to access it (in i965,
at least).
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing clip
distances 0-3, and the second containing clip distances 4-7).
However, it is declared in GLSL as an array of 8 floats.
This lowering pass acts at the GLSL level, modifying the declaration
of gl_ClipDistance so that it is an array of vec4's rather than an
array of floats, and renaming it to gl_ClipDistanceMESA. In addition,
it modifies all accesses to the array so that they access the
appropiate component of one of the vec4's.
Since some hardware may not internally represent gl_ClipDistance as a
pair of vec4's, this lowering pass is optional. To enable it, set the
LowerClipDistance flag in gl_shader_compiler_options to true.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
From section 7.1 (Vertex Shader Special Variables) of the GLSL 1.30
spec:
"It is an error for a shader to statically write both
gl_ClipVertex and gl_ClipDistance."
Fixes piglit test mixing-clip-distance-and-clip-vertex-disallowed.c.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It's the same as GL_AMD_conservative_depth. The specs have slight
differences in wording, but don't differ in content or behavior.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
At least one of the invariants verified by IR validation concerns the
relative ordering of toplevel constructs in the IR: references to
global variables must come after the declarations of those global
variables.
Since linking affects the ordering of toplevel constructs in the IR,
it's possible that a bug in the linker will cause invalid IR to be
generated, even if all the pre-linked shaders are valid. (In fact,
such a bug was fixed by the previous commit.)
Bugs like this are easily masked by further optimization passes,
particularly inlining. So to make them easier to track down, this
patch addes an IR validation step right after linking, and before
final optimization occurs. The validation only occurs on debug
builds.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
linker_warning is a new function. It's identical to linker_error
except that it doesn't set LinkStatus=false and it prepends "warning: "
on messages instead of "error: ".
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Remove the other places that set LinkStatus to false since they all
immediately follow a call to linker_error. The function linker_error
was previously known as linker_error_printf. The name was changed
because it may seem surprising that a printf function will set an
error flag.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The GLSL 1.20 and later specs say:
"Recursion is not allowed, not even statically. Static recursion is
present if the static function call graph of the program contains
cycles."
Recursion is detected and rejected both a compile-time and at
link-time. The complie-time check happens to detect some cases that
may be removed by various optimization passes. The spec doesn't seem
to allow this, but other vendors (e.g., NVIDIA) appear to only check
at link-time after all optimizations.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33885
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes an assertion failure in the piglib out-01.frag
ARB_explicit_attrib_location test. The locations set via the layout
qualifier in fragment shader were not being applied to the shader
outputs. As a result all of these variables still had a location of
-1 set.
This may need some more work for pre-3.0 contexts. The problem is
dealing with generic outputs that lack a layout qualifier. There is
no way for the application to specify a location
(glBindFragDataLocation is not supported) or query the location
assigned by the linker (glGetFragDataLocation is not supported).
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38624
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Vinson Lee <vlee@vmware.com>
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This should be the last bit of infrastructure changes before
generating GLSL IR for assembly shaders.
This commit leaves some odd code formatting in ir_to_mesa and brw_fs.
This was done to minimize whitespace changes / reindentation in some
loops. The following commit will restore formatting sanity.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Arrays are zero based. If the highest element accessed is 6, the
array needs to have 7 elements.
Fixes piglit test glsl-fs-implicit-array-size-03 and bugzilla #34198.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
This annotation is for an "in" function parameter for which it is only legal
to pass constant expressions. The only known example of this, currently,
is the textureOffset functions.
This should never be used for globals.
From the AMD_conservative_depth spec:
If gl_FragDepth is redeclared in any fragment shader in a program, it
must be redeclared in all fragment shaders in that program that have
static assignments to gl_FragDepth. All redeclarations of gl_FragDepth in
all fragment shaders in a single program must have the same set of
qualifiers.
Update the max_array_access of a global as functions that use that
global are pulled into the linked shader.
Fixes piglit test glsl-fs-implicit-array-size-01 and bugzilla #33219.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
Previously only global arrays with implicit sizes would be patched.
This causes all arrays that are actually accessed to be sized.
Fixes piglit test glsl-fs-implicit-array-size-02.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
That's what I get for not running piglit before pushing.
Don't try to patch types of unsized arrays when linking fails.
Don't try to patch types of unsized arrays that are shared between
shader stages.
Fixes piglit test case glsl-vec-array (bugzilla #31908).
NOTE: This bug does not affect 7.9, but I think this patch is a
candiate for the 7.9 branch anyway.
Previously, IR for a linked shader was allocated directly out of the
gl_shader object - meaning all of it lived as long as the shader.
Now, IR is allocated out of a temporary context, and any -live- IR is
reparented/stolen to (effectively) the gl_shader. Any remaining IR can
be freed.
NOTE: This is a candidate for the 7.9 branch.
Previously some shader input or outputs that hadn't received location
assignments could slip through. This could happen when a shader
contained user-defined varyings and was used with either
fixed-function or assembly shaders.
See the piglit tests glsl-[fv]s-user-varying-ff and
sso-user-varying-0[12].
NOTE: this is a candidate for the 7.9 branch.
