[Mesa-dev] [PATCH v6] nir: Add an ALU op builder kind of like ir_builder.h

[Olivier Galibert]

  Hi,

I thought mesa was C++ by now?  That API is really C-ish.

  OG.


On Wed, Feb 18, 2015 at 2:12 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On Friday, February 06, 2015 04:00:10 PM Eric Anholt wrote:
>> v2: Rebase on the nir_opcodes.h python code generation support.
>> v3: Use SSA values, and set an appropriate writemask on dot products.
>> v4: Make the arguments be SSA references as well.  This lets you stack up
>>     expressions in the arguments of other expressions, at the cost of
>>     having to insert a fmov/imov if you want to swizzle.  Also, add
>>     the generated file to NIR_GENERATED_FILES.
>> v5: Use more pythonish style for iterating the list.
>> v6: Infer the size of the dest from the size of the srcs, and auto-swizzle
>>     a single small src out to the appropriate size.
>> ---
>>  src/glsl/Makefile.am                  |   5 ++
>>  src/glsl/Makefile.sources             |   1 +
>>  src/glsl/nir/.gitignore               |   1 +
>>  src/glsl/nir/nir_builder.h            | 114 ++++++++++++++++++++++++++++++++++
>>  src/glsl/nir/nir_builder_opcodes_h.py |  38 ++++++++++++
>>  5 files changed, 159 insertions(+)
>>  create mode 100644 src/glsl/nir/nir_builder.h
>>  create mode 100644 src/glsl/nir/nir_builder_opcodes_h.py
>
> This patch is:
> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
>
> I do like Connor's ideas - we should definitely extend this and use it
> in more places.  I think we can easily do that as a follow on series.
>
> It might make sense to (eventually) have an API like:
>
> nir_builder *nir_builder_create(...)
>
> nir_builder_insert_at_cf_list(nir_builder *b, nir_cf_list *cf_list)
> nir_builder_insert_at_block_start(nir_builder *b, nir_bblock *block)
> nir_builder_insert_at_block_end(nir_builder *b, nir_bblock *block)
> nir_builder_insert_after_instr(nir_builder *b, nir_instruction *instr)
> nir_builder_insert_before_instr(nir_builder *b, nir_instruction *instr)
>
> I could see us having to store a cf_list/bblock/instr and needing to
> swap around several fields, so having functions would be nicer than
> prodding at struct fields directly.
>
> But for now, I think it's sufficient - it'll be easy enough to create
> later, when we actually make the other APIs and start using them.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>