[Mesa-dev] [PATCH 09/12] nir: Add lowering support for packing opcodes.
Matt Turner
mattst88 at gmail.com
Thu Jan 28 09:21:40 PST 2016
On Thu, Jan 28, 2016 at 12:32 AM, Iago Toral <itoral at igalia.com> wrote:
> On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
>> ---
>> src/glsl/nir/nir.h | 4 ++++
>> src/glsl/nir/nir_lower_alu_to_scalar.c | 32 ++++++++++++++++++++++++++++++++
>> src/glsl/nir/nir_opcodes.py | 10 ++++++++++
>> src/glsl/nir/nir_opt_algebraic.py | 20 ++++++++++++++++++++
>> 4 files changed, 66 insertions(+)
>>
>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>> index 7b39cbb..bbd5b1a 100644
>> --- a/src/glsl/nir/nir.h
>> +++ b/src/glsl/nir/nir.h
>> @@ -1469,6 +1469,10 @@ typedef struct nir_shader_compiler_options {
>> bool lower_ffract;
>>
>> bool lower_pack_half_2x16;
>> + bool lower_pack_unorm_2x16;
>> + bool lower_pack_snorm_2x16;
>> + bool lower_pack_unorm_4x8;
>> + bool lower_pack_snorm_4x8;
>> bool lower_unpack_half_2x16;
>>
>> bool lower_extract_byte;
>> diff --git a/src/glsl/nir/nir_lower_alu_to_scalar.c b/src/glsl/nir/nir_lower_alu_to_scalar.c
>> index 5372fbe..37cb022 100644
>> --- a/src/glsl/nir/nir_lower_alu_to_scalar.c
>> +++ b/src/glsl/nir/nir_lower_alu_to_scalar.c
>> @@ -134,6 +134,38 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b)
>> return;
>> }
>>
>> + case nir_op_pack_uvec2_to_uint: {
>> + assert(b->shader->options->lower_pack_snorm_2x16 ||
>> + b->shader->options->lower_pack_unorm_2x16);
>
> So we only want opt_algebraic to generate these opcodes? Why? I see that
> this would be the case now, and it is true that there is probably no
> reason for other IR -> NIR translators to inject these opcodes directly
> without going through opt_algebraic, but do we need to prevent that with
> an assert?
Not really necessary to assert, but I certainly don't expect there to
be other uses of these opcodes.
> I am not against anyway, just curious.
>
>> + nir_ssa_def *word =
>> + nir_extract_uword(b, instr->src[0].src.ssa, nir_imm_int(b, 0));
>> + nir_ssa_def *val =
>> + nir_ior(b, nir_ishl(b, nir_channel(b, word, 1), nir_imm_int(b, 16)),
>> + nir_channel(b, word, 0));
>> +
>> + nir_ssa_def_rewrite_uses(&instr->dest.dest.ssa, nir_src_for_ssa(val));
>> + nir_instr_remove(&instr->instr);
>> + break;
>> + }
>> +
>> + case nir_op_pack_uvec4_to_uint: {
>> + assert(b->shader->options->lower_pack_snorm_4x8 ||
>> + b->shader->options->lower_pack_unorm_4x8);
>> +
>> + nir_ssa_def *byte =
>> + nir_extract_ubyte(b, instr->src[0].src.ssa, nir_imm_int(b, 0));
>> + nir_ssa_def *val =
>> + nir_ior(b, nir_ior(b, nir_ishl(b, nir_channel(b, byte, 3), nir_imm_int(b, 24)),
>> + nir_ishl(b, nir_channel(b, byte, 2), nir_imm_int(b, 16))),
>> + nir_ior(b, nir_ishl(b, nir_channel(b, byte, 1), nir_imm_int(b, 8)),
>> + nir_channel(b, byte, 0)));
>> +
>> + nir_ssa_def_rewrite_uses(&instr->dest.dest.ssa, nir_src_for_ssa(val));
>> + nir_instr_remove(&instr->instr);
>> + break;
>> + }
>> +
>> case nir_op_fdph: {
>> nir_ssa_def *sum[4];
>> for (unsigned i = 0; i < 3; i++) {
>> diff --git a/src/glsl/nir/nir_opcodes.py b/src/glsl/nir/nir_opcodes.py
>> index be3cd17..3b82c3c 100644
>> --- a/src/glsl/nir/nir_opcodes.py
>> +++ b/src/glsl/nir/nir_opcodes.py
>> @@ -237,6 +237,16 @@ unpack_2x16("unorm")
>> unpack_4x8("unorm")
>> unpack_2x16("half")
>>
>> +unop_horiz("pack_uvec2_to_uint", 0, tuint, 2, tuint, """
>> +dst = (src0.x & 0xffff) | (src0.y >> 16);
>> +""")
>
> This should've 1 as the output size instead of 0.
I think there's a subtle (and perhaps meaningless) distinction between
0 and 1. I think that 0 gives a scalar (uint) while 1 gives a
1-component vector. The only difference I've seen is the use of dst vs
dst.x in the constant evaluation code.
Do you know of any other differences or a reason to prefer 1 over 0?
>> +unop_horiz("pack_uvec4_to_uint", 0, tuint, 4, tuint, """
>> +dst = (src0.x << 0) |
>> + (src0.y << 8) |
>> + (src0.z << 16) |
>> + (src0.w << 24);
>> +""")
>
> Same here.
>
>
>> # Lowered floating point unpacking operations.
>>
>> diff --git a/src/glsl/nir/nir_opt_algebraic.py b/src/glsl/nir/nir_opt_algebraic.py
>> index b761b54..56b0f5e 100644
>> --- a/src/glsl/nir/nir_opt_algebraic.py
>> +++ b/src/glsl/nir/nir_opt_algebraic.py
>> @@ -258,6 +258,26 @@ optimizations = [
>> (('extract_uword', a, b),
>> ('iand', ('ushr', a, ('imul', b, 16)), 0xffff),
>> 'options->lower_extract_word'),
>> +
>> + (('pack_unorm_2x16', 'v'),
>> + ('pack_uvec2_to_uint',
>> + ('f2u', ('fround_even', ('fmul', ('fsat', 'v'), 65535.0)))),
>> + 'options->lower_pack_unorm_2x16'),
>> +
>> + (('pack_unorm_4x8', 'v'),
>> + ('pack_uvec4_to_uint',
>> + ('f2u', ('fround_even', ('fmul', ('fsat', 'v'), 255.0)))),
>> + 'options->lower_pack_unorm_4x8'),
>> +
>> + (('pack_snorm_2x16', 'v'),
>> + ('pack_uvec2_to_uint',
>> + ('f2i', ('fround_even', ('fmul', ('fmin', 1.0, ('fmax', -1.0, 'v')), 32767.0)))),
>> + 'options->lower_pack_snorm_2x16'),
>> +
>> + (('pack_snorm_4x8', 'v'),
>> + ('pack_uvec4_to_uint',
>> + ('f2i', ('fround_even', ('fmul', ('fmin', 1.0, ('fmax', -1.0, 'v')), 127.0)))),
>> + 'options->lower_pack_snorm_4x8'),
>
> I think the pack_snorm_* opcodes need a i2u conversion at the end.
> That's what the GLSL IR lowering is doing and also what the spec [1]
> seems to indicate:
Right, but since NIR operands are typeless, there's nothing to do (NIR
doesn't even have i2u/u2i).
More information about the mesa-dev
mailing list