Matt Turner <matts...@gmail.com> writes: > On Tue, Aug 11, 2015 at 11:25 AM, Eric Anholt <e...@anholt.net> wrote: >> Avoids regressions in vc4 when trying to do our blending in NIR. >> >> v2: Add the other unpack ops I meant to when writing the original commit >> message. >> --- >> src/glsl/nir/nir_lower_alu_to_scalar.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/src/glsl/nir/nir_lower_alu_to_scalar.c >> b/src/glsl/nir/nir_lower_alu_to_scalar.c >> index 5d15fb2..efbe9e7 100644 >> --- a/src/glsl/nir/nir_lower_alu_to_scalar.c >> +++ b/src/glsl/nir/nir_lower_alu_to_scalar.c >> @@ -100,6 +100,21 @@ lower_alu_instr_scalar(nir_alu_instr *instr, void >> *mem_ctx) >> */ >> return; >> >> + case nir_op_unpack_unorm_4x8: >> + case nir_op_unpack_snorm_4x8: >> + case nir_op_unpack_unorm_2x16: >> + case nir_op_unpack_snorm_2x16: >> + /* There is no scalar version of these ops, unless we were to break it >> + * down to bitshifts and math (which is definitely not intended). >> + */ >> + return; >> + >> + case nir_op_unpack_half_2x16: >> + /* We could split this into unpack_half_2x16_split_[xy], but should >> + * we? >> + */ >> + return; >> + > > Reviewed-by: Matt Turner <matts...@gmail.com> > > Seems like we should we add the pack opcodes as well?
I don't think any of the pack opcodes produce a vector value.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
