| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This points to the object with the function body, allowing us to map
from a built-in prototype to the actual body with IR code to execute.
Signed-off-by: Olivier Galibert <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
The index is also used for GL_ARB_blend_func_extended. Cloning in
i965 was dropping a non-ARB_explicit_attrib_location index.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds index support to the GLSL compiler.
I'm not 100% sure of my approach here, esp without how output ordering
happens wrt location, index pairs, in the "mark" function.
Since current hw doesn't ever have a location > 0 with an index > 0,
we don't have to work out if the output ordering the hw requires is
location, index, location, index or location, location, index, index.
But we have no hw to know, so punt on it for now.
v2: index requires layout - catch and error
setup explicit index properly.
v3: drop idx_offset stuff, assume index follow location
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, set_callee() performed some assertions about the type of the
ir_call; protecting the bare pointer ensured these checks would be run.
However, ir_call no longer has a type, so the getter and setter methods
don't actually do anything useful. Remove them in favor of accessing
callee directly, as is done with most other fields in our IR.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aside from ir_call, our IR is cleanly split into two classes:
- Statements (typeless; used for side effects, control flow)
- Values (deeply nestable, pure, typed expression trees)
Unfortunately, ir_call confused all this:
- For void functions, we placed ir_call directly in the instruction
stream, treating it as an untyped statement. Yet, it was a subclass
of ir_rvalue, and no other ir_rvalue could be used in this way.
- For functions with a return value, ir_call could be placed in
arbitrary expression trees. While this fit naturally with the source
language, it meant that expressions might not be pure, making it
difficult to transform and optimize them. To combat this, we always
emitted ir_call directly in the RHS of an ir_assignment, only using
a temporary variable in expression trees. Many passes relied on this
assumption; the acos and atan built-ins violated it.
This patch makes ir_call a statement (ir_instruction) rather than a
value (ir_rvalue). Non-void calls now take a ir_dereference of a
variable, and store the return value there---effectively a call and
assignment rolled into one. They cannot be embedded in expressions.
All expression trees are now pure, without exception.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, ir_call can be used as either a statement (for void
functions) or a value (for non-void functions). This is rather awkward,
as it's the only class that can be used in both forms.
A number of places use ir_call::get_error_instruction() to construct a
generic value of error_type. If ir_call is to become a statement, it
can no longer serve this purpose.
Unfortunately, none of our classes are particularly well suited for
this, and creating a new one would be rather aggrandizing. So, this
patch introduces ir_rvalue::error_value(), a static method that creates
an instance of the base class, ir_rvalue. This has the nice property
that you can't accidentally try and access uninitialized fields (as it
doesn't have any). The downside is that the base class is no longer
abstract.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
| |
This fixes AMD_conservative_depth.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34687
Reviewed-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Having a few of these includes or forward declarations inside the
'extern "C"' block can cause problems later. Specifically, it
prevents C++ linkage functions from being added to ir_to_mesa.h and
makes G++ angry if 'struct foo' is seen both inside and outside an
'extern "C"'.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The array_lvalue field was attempting to enforce the restriction that
whole arrays can't be used on the left-hand side of an assignment in
GLSL 1.10 or GLSL ES, and can't be used as out or inout parameters in
GLSL 1.10.
However, it was buggy (it didn't work properly for built-in arrays),
and it was clumsy (it unnecessarily kept track on a
variable-by-variable basis, and it didn't cover the GLSL ES case).
This patch removes the array_lvalue field completely in favor of
explicit checks in ast_parameter_declarator::hir() (this check is
added) and in do_assignment (this check was already present).
This causes a benign behavioral change: when the user attempts to pass
an array as an out or inout parameter of a function in GLSL 1.10, the
error is now flagged at the time the function definition is
encountered, rather than at the time of invocation. Previously we
allowed such functions to be defined, and only flagged the error if
they were invoked.
Fixes Piglit tests
spec/glsl-1.10/compiler/qualifiers/fn-{out,inout}-array-prohibited*
and
spec/glsl-1.20/compiler/assignment-operators/assign-builtin-array-allowed.vert.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
One unique aspect of TXS is that it doesn't have a coordinate.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
This allows us to reuse some code and will be useful later.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
Those have the callee field set to the null pointer, so
calling the public constructor will segfault.
Signed-off-by: Tilman Sauerbeck <[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.
|
| |
|
|
|
| |
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]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
glsl-arb-fragment-coord-conventions
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Since GLSL permits arrays of structures, we need to store each element
as an ir_constant*, not just ir_constant_data.
Fixes parser tests const-array-01.frag, const-array-03.frag,
const-array-04.frag, const-array-05.frag, though 03 and 04 generate the
wrong code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is quite a large patch because breaking it into smaller pieces
would result in the tree being intermitently broken. The big changes
are:
* Add the ir_var_temporary variable mode
* Change the ir_variable constructor to take the mode as a
parameter and correctly specify the mode for all ir_varables.
* Change the linker to not cross validate ir_var_temporary
variables.
* Change the linker to pull all ir_var_temporary variables from
global scope into 'main'.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This currently involves an ugly hack so that every link doesn't result
in all the built-in functions showing up as multiply defined. As soon
as the built-in functions are stored in a separate compilation unit,
ir_function_signature::is_built_in can be removed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is as opposed to returning the type of the base class of the hierarchy.
|
| | |
|
| | |
|
| |
|
