We resolved the implicit version directive when processing control lines,
such as #ifdef, to ensure any built-in macros exist. However, we failed
to resolve it when handling ordinary text.
For example,
int x = __VERSION__;
should resolve __VERSION__ to 110, but since we never resolved the implicit
version, none of the built-in macros exist, so it was left as is.
This also meant we allowed the following shader to slop through:
123
#version 120
Nothing would cause the implicit version to take effect, so when we saw
the #version directive, we thought everything was peachy.
This patch makes the lexer's per-token action resolve the implicit
version on the first non-space/newline/hash token that isn't part of
a #version directive, fulfilling the GLSL language spec:
"The #version directive must occur in a shader before anything else,
except for comments and white space."
Because we emit #version as HASH_TOKEN then VERSION_TOKEN, we have to
allow HASH_TOKEN to slop through as well, so we don't resolve the
implicit version as soon as we see the # character. However, this is
fine, because the parser's HASH_TOKEN NEWLINE rule does resolve the
version, disallowing cases like:
#
#version 120
This patch also adds the above shaders as new glcpp tests.
Fixes dEQP-GLES2.functional.shaders.preprocessor.predefined_macros.
{gl_es_1_vertex,gl_es_1_fragment}.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Not a currently tested configuration, but these couple of small changes
allow a 32-bit build.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94383
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Brian Paul <brianp@vmware.com>
In a shader such as:
struct S { float f; }
float identity(float S) { return S; }
we would think that "S" in "return S" referred to a structure, even
though it's shadowed by the "float S" parameter in the inner struct.
This led to the parser's grammar seeing TYPE_IDENTIFIER and getting
confused.
Fixes dEQP-GLES2.functional.shaders.scoping.valid.
function_parameter_hides_struct_type_{vertex,fragment}.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The lexer/parser use a symbol table to classify identifiers as
variables, functions, or structure types.
For some reason, we neglected to add variables in simple declarations
such as
int x = 5;
but did add subsequent variables in multi-declarations:
int x = 5, y = 6; // y gets added, but not x, for some reason
Fixes four dEQP-GLES2.functional.shaders.scoping.valid subcases:
- local_int_variable_hides_struct_type_vertex
- local_int_variable_hides_struct_type_fragment
- local_struct_variable_hides_struct_type_vertex
- local_struct_variable_hides_struct_type_fragment
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
If glGenerateMipmap was called with a bogus target, then it would
pass that to _mesa_get_current_tex_object(), which would raise a
_mesa_problem() telling people to file bugs. We'd then do the
proper error checking, raise an error, and bail.
Doing the check first avoids the _mesa_problem(). The DSA variant
doesn't take a target parameter, so we leave the target validation
exactly as it was in that case.
Fixes one dEQP GLES2 test:
dEQP-GLES2.functional.negative_api.texture.generatemipmap.invalid_target.
v2: Rebase on Antia's recent patch to this area.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
This allows to perform atomic operations on shared memory.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The SHARED TGSI keyword is only allowed with TGSI_FILE_MEMORY and not
with TGSI_FILE_BUFFER. I have found this by using the nouveau_compiler
from command line.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
The limit of the thread count immediate value is 12 bits.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
To know when we're flushing the command buffer because we need to
write to surface in the command buffer.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
In the rather unusual case of Bind + Delete, we need to make sure that
we unbind the current tf object.
Fixes dEQP-GLES3.functional.lifetime.delete_bound.transform_feedback
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes a crash in
dEQP-GLES3.functional.transform_feedback.array_element.separate.points.lowp_mat3x2
and likely others. The vertex shader has > 16 input variables (without
explicit locations), which causes us to index outside of the to_assign
array.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
This simplifies the code that iterates over the per-component values
found in the matching copy_entry struct and checks whether the
register regions that were copied to each component are similar enough
to be treated as a single (reswizzled) value which can be propagated
into the current instruction.
Aside from being scattered between opt_copy_propagation(),
try_copy_propagate(), and try_constant_propagate(), what I found
terribly confusing about the preexisting logic was that
opt_copy_propagation() tried to reorder the array of values according
to the swizzle of the instruction source, which meant one would have
had to invert the reordering applied at the top level in order to find
out which component to take from each value (we were just taking the
i-th component from the i-th value, which is not correct in general).
The saturate mask was also being swizzled incorrectly.
This consolidates the logic for matching multiple components of a
copy_entry into a single function which returns the result as a
regular src_reg on success, as if the copy had been performed with a
single MOV instruction copying all components of the src_reg into the
destination.
Fixes several ARB_vertex_program MOV test-cases from:
https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program
Acked-by: Matt Turner <mattst88@gmail.com>
Scalar immediates used to be handled correctly by swizzle() (as the
identity) but since commit 58fa9d47b5 it
will corrupt the contents of the immediate. Vector immediates were
never handled correctly, but we had ad-hoc code to swizzle VF
immediates in the vec4 copy propagation pass. This takes care of
swizzling V and UV in addition.
v2: Don't implement swizzling of V/UV immediates (Matt). If you need
to swizzle an integer vector immediate in the future apply the
following diff to go back to v1:
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -119,11 +119,10 @@ brw_swap_cmod(uint32_t cmod)
static unsigned
imm_shift(enum brw_reg_type type, unsigned i)
{
- assert(type != BRW_REGISTER_TYPE_UV && type != BRW_REGISTER_TYPE_V &&
- "Not implemented.");
-
if (type == BRW_REGISTER_TYPE_VF)
return 8 * (i & 3);
+ else if (type == BRW_REGISTER_TYPE_UV || type == BRW_REGISTER_TYPE_V)
+ return 4 * (i & 7);
else
return 0;
}
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
And replace brw_swizzle1() with brw_swizzle(). Seems slightly cleaner
and will allow reusing brw_swizzle() in the vec4 back-end more easily.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes some use-after-free situations in dEQP when an xfb state is
removed, and then a clear is triggered, which only does a partial
validation. It would attempt to read the no-longer-valid buffers,
resulting in crashes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
The OES extensions clarify this behaviour to differentiate between
per-sample invocation and per-sample interpolation. Using sampleid/pos
will force per-sample invocation but not per-sample interpolation.
See https://www.khronos.org/bugzilla/show_bug.cgi?id=1462
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Since commit 922be4eab, the expectation is that the query result
contains the correct value. Unfortunately swrast does not distinguish
between GL_SAMPLES_PASSED and GL_ANY_SAMPLES_PASSED. As a result, we
must fix up the query result in a post-draw fixup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94274
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
compute.c: In function ‘launch_grid’:
compute.c:435:20: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
info.input = input;
^
Maybe the pipe_grid_info::input field should be const void *?
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
From Section 4.4.5 (Uniform and Shader Storage Block Layout
Qualifiers) of the OpenGL 4.50 spec:
"The align qualifier makes the start of each block member have a
minimum byte alignment. It does not affect the internal layout
within each member, which will still follow the std140 or std430
rules. The specified alignment must be a power of 2, or a
compile-time error results.
The actual alignment of a member will be the greater of the
specified align alignment and the standard (e.g., std140) base
alignment for the member's type. The actual offset of a member is
computed as follows: If offset was declared, start with that
offset, otherwise start with the next available offset. If the
resulting offset is not a multiple of the actual alignment,
increase it to the first offset that is a multiple of the actual
alignment. This results in the actual offset the member will have.
When align is applied to an array, it affects only the start of
the array, not the array's internal stride. Both an offset and an
align qualifier can be specified on a declaration.
The align qualifier, when used on a block, has the same effect as
qualifying each member with the same align value as declared on
the block, and gets the same compile-time results and errors as if
this had been done. As described in general earlier, an individual
member can specify its own align, which overrides the block-level
align, but just for that member.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The old comment was for the location not the offset, we now use
the field for block members so mention that also.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
In this patch we also copy the offset value from the ast and
implement offset linking rules by adding it to the record_compare()
function.
From Section 4.4.5 (Uniform and Shader Storage Block Layout Qualifiers)
of the GLSL 4.50 spec:
"Two blocks linked together in the same program with the same block
name must have the exact same set of members qualified with
offset and their integral-constant-expression values must be the
same, or a link-time error results."
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This implements the rules for the offset qualifier on block members.
From Section 4.4.5 (Uniform and Shader Storage Block Layout Qualifiers)
of the GLSL 4.50 spec:
"The offset qualifier can only be used on block members of blocks
declared with std140 or std430 layouts."
...
"It is a compile-time error to specify an offset that is smaller than
the offset of the previous member in the block or that lies within the
previous member of the block."
...
"The specified offset must be a multiple of the base alignment of the
type of the block member it qualifies, or a compile-time error results."
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Global in validation is already handled, this will do the validation
for variables, blocks and block members.
This fixes some CTS tests for the new enhanced layouts transform
feedback qualifiers.
V2: add some more valid input flags
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Previously interface blocks were giving the global default flags of
uniform blocks. This meant we could not check for invalid qualifiers
on interface blocks because they always contained invalid flags.
This changes parsing so that interface blocks now get an empty
set of layouts.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
If the following patch we will stop setting these layouts by default
on interface blocks, so we need to do this to avoid hitting the
assert.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Kenneth Graunke
Tim Rowley
Samuel Pitoiset
Brian Paul
Ilia Mirkin
Francisco Jerez
Timothy Arceri