| Age | Commit message (Collapse) | Author |
|---|
|
This eliminates the need in some cames to validate that an rvalue is
an ir_constant before checking to see if it's 0 or 1.
|
|
Fix this GCC warning.
ir.cpp: In static member function
'static unsigned int ir_expression::get_num_operands(ir_expression_operation)':
ir.cpp:199: warning: control reaches end of non-void function
|
|
The new usage message lists possible command line options. (Newcomers to Mesa
currently have to trawl through the source to find the command line options,
and we should save them from that trouble.)
Example Output
--------------
usage: ./glsl_compiler [options] <file.vert | file.geom | file.frag>
Possible options are:
--glsl-es
--dump-ast
--dump-hir
--dump-lir
--link
|
|
This adds sentinel values to the ir_expression_operation enum type:
ir_last_unop, ir_last_binop, and ir_last_opcode. They are set to the
previous one so they don't trigger "unhandled case in switch statement"
warnings, but should never be handled directly.
This allows us to remove the huge array of 1s and 2s in
ir_expression::get_num_operands().
|
|
|
|
|
|
We are not aware of any GPU that actually implements the cross product
as a single instruction. Hence, there's no need for it to be an opcode.
Future commits will remove it entirely.
|
|
|
|
This is really supposed to be defined only if the driver supports highp
in the fragment shader - but all of our current ES2 implementations do.
So, just define it. In the future, we'll need to add a flag to
gl_context and only define the macro if the flag is set.
"Fixes" freedesktop.org bug #31673.
|
|
|
|
Return values were erroneously cast from (ir_rvalue*) to (ir_expression*).
NOTE: This is a candidate for the 7.9 branch.
|
|
ir_binop_less, ir_binop_greater, ir_binop_lequal, and ir_binop_gequal
are defined to work on vectors as well as scalars, as long as the two
operands have the same type.
This is evident from both ir_validate.cpp and our use of these opcodes
in the GLSL lessThan, greaterThan, lessThanEqual, greaterThanEqual
built-in functions.
Found by code inspection. Not known to fix any bugs. Presumably, our
tests for the built-in comparison functions must pass because C.E.
handling is done on the ir_call of "greaterThan" rather than the inlined
opcode. The C.E. handling of the built-in function calls is correct.
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
Per section 4.5.4 of the GLSL 1.30 specification.
|
|
|
|
These predicates will be used in other places soon.
|
|
This was accidentally removed in commit 32aaf89823de11e98cb59d5ec78c66cd3e74bcd4.
Fixes SCons builds.
|
|
And alphabetize the opt_* files.
|
|
|
|
This helps distinguish between lowering passes, optimization passes, and
other compiler code.
|
|
This was from when glsl2 lived in a separate repository and used
automake.
|
|
|
|
|
|
|
|
|
|
For the last three commits.
|
|
|
|
|
|
This consolidates the TOKEN_OR_IDENTIFIER and RESERVED_WORD macros into
a single KEYWORD macro.
The old TOKEN_OR_IDENTIFIER macros handled the case of a word going from
an identifier to a keyword; the RESERVED_WORD macro handled a word going
from a reserved word to a language keyword. However, neither could
properly handle samplerBuffer (for example), which is an identifier in
1.10 and 1.20, a reserved word in 1.30, and a keyword in 1.40 and on.
Furthermore, the existing macros didn't properly handle reserved words
in GLSL ES 1.00. The best they could do was return a token (rather than
an identifier), resulting in an obtuse parser error, rather than a
user-friendly "you used a reserved word" error message.
|
|
This is nice because printing type->base_type in GDB will now give you a
readable name instead of a number.
|
|
Functions are not first class objects in GLSL, so there is never a value
of function type. No code actually used this except for one function
which asserted it shouldn't occur. One comment mentioned it, but was
incorrect. So we may as well remove it entirely.
|
|
Since this was talloced off of NULL instead of the compile state, it
was a real leak over the course of the program. Noticed with
valgrind --leak-check=full --show-reachable=yes. We should really
change these passes to generally get the compile context as an argument
so simple mistakes like this stop mattering.
|
|
Fixes loop-07.frag.
|
|
The "instructions" variable -is- used, so the cast to void can go away.
|
|
NOTE: this is a candidate for the 7.9 branch.
|
|
When the type of the ir_expression is error_type, return NULL.
This fixes bug 31371.
|
|
This makes linked shaders use around 36k less memory since the
built-in prototypes are now freed.
|
|
|
|
Found by inspection.
|
|
It's already been determined that length == 3, so clearly swiz->next is
a valid S-Expression.
|
|
There's really no reason to return the base class when we have more
specific information about what type it is.
|
|
We really only want to print spaces -between- elements, not after each
element. This cleans up error messages from IR reader, making them
(mildly) easier to read.
|
|
|
|
In particular, calling the abs function is silly, since there's already
an expression opcode for that. Also, assigning to temporaries then
assigning those to the final location is rather redundant.
|
|
For consistency with the vec2/vec3/vec4 variants.
|
|
It's also equivalent to Elements(...) which is already used elsewhere.
|
|
First, it changes autoconf to use a "python2" binary when available,
rather than plain "python" (which is ambiguous). Secondly, it changes
the Makefiles to use $(PYTHON) $(PYTHON_FLAGS) rather than calling
python directly.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Matthew William Cox <matt@mattcox.ca>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Fixes freedesktop.org bug #31101 as well as piglit test cases
assignment-type-mismatch.vert and constructor-28.vert.
|
|
Function ast_declarator_list::hir(), when processing keywords added by
extension ARB_fragment_coord_conventions, made the mistake of checking only if
the extension was __supported by the driver__. The correct behavior is to check
if the extensi0n is __enabled in the parse state__.
NOTE: this is a candidate for the 7.9 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Since this is just generated by python, it's questionable whether this
should continue to live in the repository - Mesa already has other
things generated from python as part of the build process.
|
