| Age | Commit message (Collapse) | Author |
|---|
|
This isn't strictly necessary, but is definitely nicer.
|
|
These mistakenly computed 't' instead of t * t * (3.0 - 2.0 * t).
Also, properly vectorize the smoothstep(float, float, vec) variants.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
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.
|
|
|
|
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.
|
|
|
|
This implements round() via the ir_unop_round_even opcode, rather than
adding a new opcode. We may wish to add one in the future, since it
might enable a small performance increase on some hardware, but for now,
this should suffice.
|
|
Implemented using the op-code introduced in the previous commit.
|
|
|
|
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 <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
Commit 309cd4115b7cba669a0bf858e7809cb6dae90ddf incorrectly converted
these to all_equal and any_nequal, which is the wrong operation.
|
|
|
|
|
|
|
|
These need abs, and we need more tests.
|
|
|
|
ir_binop_dot is only defined for vector types. Use ir_binop_mul.
|
|
The code being generated was just stupid, considering that:
- normalize(x) = 1.0
- length(x) = x
- distance(x, y) = x - y
|
|
|
|
|
|
When x==0, the result was wrong. Fixes piglit glsl-fs-atan-1.shader_test
|
|
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)
|
|
Each language version/extension and target now has a "profile" containing
all of the available builtin function prototypes. These are written in
GLSL, and come directly out of the GLSL spec (except for expanding genType).
A new builtins/ir/ folder contains the hand-written IR for each builtin,
regardless of what version includes it. Only those definitions that have
prototypes in the profile will be included.
The autogenerated IR for texture builtins is no longer written to disk,
so there's no longer any confusion as to what's hand-written or
generated.
All scripts are now in python instead of perl.
|
