[Mesa-dev] [PATCH 2/2] nir: Don't try to scalarize unpack ops.

[Eric Anholt]

Matt Turner <mattst88 at gmail.com> writes:

> On Tue, Aug 11, 2015 at 11:25 AM, Eric Anholt <eric at 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 <mattst88 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150811/43578a2e/attachment.sig>