| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Having these as actual integer values makes it difficult to implement
the texture*Offset built-in functions, since the offset is actually a
function parameter (which doesn't have a constant value).
The original rationale was that some hardware needs these offset baked
into the instruction opcode. However, at least i965 should be able to
support non-constant offsets. Others should be able to rely on inlining
and constant propagation.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/draw/draw_llvm.c
src/gallium/drivers/llvmpipe/lp_state_fs.c
src/glsl/ir_set_program_inouts.cpp
src/mesa/tnl/t_vb_program.c
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In particular, variables cannot be redeclared invariant after being
used.
Fixes piglit test invariant-05.vert and bugzilla #29164.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
| |
| |
| |
| |
| |
| | |
I think was used long ago, when we actually read the builtins into the
shader's instruction stream directly, rather than creating a separate
shader and linking the two. It doesn't seem to serve any purpose now.
|
| |
| |
| |
| | |
This allows us to reuse some code and will be useful later.
|
| |
| |
| |
| |
| |
| | |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
| |
These predicates will be used in other places soon.
|
|
|
|
| |
It's also equivalent to Elements(...) which is already used elsewhere.
|
|
|
|
| |
Also, update ir_to_mesa's "1.30 is unsupported" case to "handle" it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that most people new to this IR are surprised when an
assignment to (say) 3 components on the LHS takes 4 components on the
RHS. It also makes for quite strange IR output:
(assign (constant bool (1)) (x) (var_ref color) (swiz x (var_ref v) ))
(assign (constant bool (1)) (y) (var_ref color) (swiz yy (var_ref v) ))
(assign (constant bool (1)) (z) (var_ref color) (swiz zzz (var_ref v) ))
But even worse, even we get it wrong, as shown by this line of our
current step(float, vec4):
(assign (constant bool (1)) (w)
(var_ref t)
(expression float b2f (expression bool >=
(swiz w (var_ref x))(var_ref edge))))
where we try to assign a float to the writemasked-out x channel and
don't supply anything for the actual w channel we're writing. Drivers
right now just get lucky since ir_to_mesa spams the float value across
all the source channels of a vec4.
Instead, the RHS will now have a number of components equal to the
number of components actually being written. Hopefully this confuses
everyone less, and it also makes codegen for a scalar target simpler.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
| |
|
|
|
|
|
| |
The print visitor needs this, and the only existing user can work with
has_user_signature just as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently GLSL IR forbids any vector comparisons, and defines "ir_binop_equal"
and "ir_binop_nequal" to compare all elements and give a single bool.
This is highly unintuitive and prevents generation of optimal Mesa IR.
Hence, first rename "ir_binop_equal" to "ir_binop_all_equal" and
"ir_binop_nequal" to "ir_binop_any_nequal".
Second, readd "ir_binop_equal" and "ir_binop_nequal" with the same semantics
as less, lequal, etc.
Third, allow all comparisons to acts on vectors.
Signed-off-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts b6f15869b324ae64a00d0fe46fa3c8c62c1edb6c.
In desktop GLSL, defining a function with the same name as a built-in
hides that built-in function completely, so there would never be
built-in and user function signatures in the same ir_function.
However, in GLSL ES, overloading built-ins is allowed, and does not
hide the built-in signatures - so we're back to needing this.
|
|
|
|
|
| |
I've used this in quite a few debug commits that never reached an
up-stream tree.
|
|
|
|
|
| |
This reprents the type of comparison between the loop induction
variable and the loop termination value.
|
|
|
|
|
|
| |
Also rename it to "is_builtin" for consistency.
Signed-off-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
The previous any() implementation would generate arg0.x || arg0.y ||
arg0.z. Having an expression operation for this makes it easy for the
backend to generate something easier (DPn + SNE for 915 FS, .any
predication on 965 VS)
|
| |
|
| |
|
|
|
|
|
|
|
| |
This lets us handle arrays much better than trying to work backwards
from assembly.
Fixes fbo-drawbuffers-maxtargets on swrast (i965 needs loop unrolling)
|
|
|
|
|
|
|
|
|
| |
Fixes ir_to_mesa handling of unop_log, which used the weird ARB_vp LOG
opcode that doesn't do what we want. This also lets the multiplication
coefficients in there get constant-folded, possibly.
Fixes:
glsl-fs-log
|
|
|
|
|
|
|
|
| |
This showed up since the disabling of inlining at compile time, which
I apparently didn't regenerate piglit summary for.
Fixes:
glsl-deadcode-call.
|
|
|
|
|
|
|
|
|
| |
For a shader involving many small functions, this avoids running
optimization across all of them after they've been inlined
post-linking.
Reduces the runtime of linking and running a fragment shader from Yo
Frankie from 1.6 seconds to 0.9 seconds (-44.9%, +/- 3.3%).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I introduced this for ir_dead_code to distinguish function parameter
outvals from varying outputs. Only, since ast_to_hir's
current_function is unset when setting up function parameters (they're
needed for making the function signature in the first place), all
function parameter outvals were marked as shader outputs anyway. This
meant that an inlined function's cloned outval was marked as a shader
output and couldn't be dead-code eliminated. Instead, since
ir_dead_code doesn't even look at function parameters, just use
var->mode.
The longest Mesa IR coming out of ir_to_mesa for Yo Frankie drops from
725 instructions to 636.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace swizzles on the LHS with additional swizzles on the RHS and a
write mask in the assignment instruction. As part of this add
ir_assignment::set_lhs. Ideally we'd make ir_assignment::lhs private
to prevent erroneous writes, but that would require a lot of code
butchery at this point.
Add ir_assignment constructor that takes an explicit write mask. This
is required for ir_assignment::clone, but it can also be used in other
places. Without this, ir_assignment clones lose their write masks,
and incorrect IR is generated in optimization passes.
Add ir_assignment::whole_variable_written method. This method gets
the variable on the LHS if the whole variable is written or NULL
otherwise. This is different from
ir->lhs->whole_variable_referenced() because the latter has no
knowledge of the write mask stored in the ir_assignment.
Gut all code from ir_to_mesa that handled swizzles on the LHS of
assignments. There is probably some other refactoring that could be
done here, but that can be left for another day.
|
|
|
|
|
|
|
| |
In most cases, we needed to be reparenting the cloned IR to a
different context (for example, to the linked shader instead of the
unlinked shader), or optimization before the reparent would cause
memory usage of the original object to grow and grow.
|
|
|
|
| |
Fixes unset ir_type after inlining.
|
|
|
|
| |
This conveniently creates a zero value of whatever type you want.
|
|
|
|
|
| |
Fixes:
glsl-arb-fragment-coord-conventions
|
|
|
|
|
|
| |
This cleans up the assembly output of almost all the non-logic tests
glsl-algebraic-*. glsl-algebraic-pow-two needs love (basically,
flattening to a temporary and squaring it).
|
|
|
|
|
|
|
|
|
|
|
| |
Top-level instructions now get NULL as their default type (since type is
irrelevant for things like ir_function), while ir_rvalues get error_type
by default.
This should make it easier to tell if we've forgotten to set a type. It
also fixes some "Conditional jump or move depends on uninitialized
value" errors in valgrind caused by ir_validate examining the type of
top level ir_instructions, which weren't set.
|