| Age | Commit message (Collapse) | Author |
|---|
|
This makes a very simple 1.30 shader go from 196k of memory to 9k.
NOTE: This -may- be a candidate for the 7.9 branch, as the benefit is
substantial. However, it's not a simple change, so it may be wiser to
wait for 7.10.
|
|
This allows us to reuse some code and will be useful later.
|
|
Fixes glsl-mat-mul-1.
|
|
|
|
We were trying to emit a single ir_expression to compare the whole
thing. The backends (ir_to_mesa.cpp and brw_fs.cpp so far) expected
ir_binop_any_nequal or ir_binop_all_equal to apply to at most a vector
(with matrices broken down by the lowering pass). Break them down to
a bunch of ORed or ANDed any_nequals/all_equals.
Fixes:
glsl-array-compare
glsl-array-compare-02
glsl-fs-struct-equal
glsl-fs-struct-notequal
Bug #31909
|
|
This doesn't cover all expressions or all operand types, but it will
complain if you overreach and it allows for much greater slack on the
programmer's part.
|
|
|
|
|
|
NOTE: This is candidate for the 7.9 branch.
|
|
NOTE: This is a candidate for the 7.9 branch.
|
|
Currently, the standalone compiler tries to do function inlining before
linking shaders (including linking against the built-in functions).
This resulted in the built-in function _prototypes_ being inlined rather
than the actual function definition.
This is only known to fix a bug in the standalone compiler; most
programs should be unaffected. Still, it seems like a good idea.
NOTE: This is a candidate for the 7.9 branch.
|
|
Hardware pretty commonly has saturate modifiers on instructions, and
this can be used in codegen to produce those, without everyone else
needing to understand clamping other than min and max.
|
|
|
|
|
|
When the semantics of write masks in assignments were changed, this
code was not correctly updated.
Fixes piglit test glsl-mat-from-vec-ctor-01.
|
|
This should save on the overhead of tree-walking and provide a
convenient place to add more instruction lowering in the future.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
The vector operator collects 2, 3, or 4 scalar components into a
vector. Doing this has several advantages. First, it will make
ud-chain tracking for components of vectors much easier. Second, a
later optimization pass could collect scalars into vectors to allow
generation of SWZ instructions (or similar as operands to other
instructions on R200 and i915). It also enables an easy way to
generate IR for SWZ instructions in the ARB_vertex_program assembler.
|
|
|
|
|
|
This may grow in the near future.
|
|
The operate just like ir_unop_sin and ir_unop_cos except that they
expect their inputs to be limited to the range [-pi, pi]. Several
GPUs require this limited range for their sine and cosine
instructions, so having these as operations (along with a to-be-written
lowering pass) helps this architectures.
These new operations also matche the semantics of the
GL_ARB_fragment_program SCS instruction. Having these as operations
helps in generating GLSL IR directly from assembly fragment programs.
|
|
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.
|
|
|
|
|
