nir: use Python to autogenerate opcode information
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it was difficult
to use nir_opcodes.h to do other things like autogenerate a builder API. Now, we
store opcode information in nir_opcodes.py, and we have nir_opcodes_c.py to
generate the old nir_opcodes.c and nir_opcodes_h.py to generate nir_opcodes.h,
which contains all the enum names and gets included into nir.h like before. In
addition to solving the above problems, using Python and Mako to generate
everything means that it's much easier to add keep information centralized as we
add new things like constant propagation that require per-opcode information.
v2:
- make Opcode derive from object (Dylan)
- don't use assert like it's a function (Dylan)
- style fixes for fnoise, use xrange (Dylan)
- use iterkeys() in nir_opcodes_h.py (Dylan)
- use pydoc-style comments (Jason)
- don't make fmin/fmax commutative and associative yet (Jason)
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v3 Jason Ekstrand <jason.ekstrand@intel.com>
- Alphabetize source file lists
- Generate nir_opcodes.h in the builddir instead of the source dir
- Include $(builddir)/src/glsl/nir in the i965 build
- Rework nir_opcodes.h generation so it generates a complete header file
instead of one that has to be embedded inside an enum declaration
2015-01-22 23:32:14 -05:00
|
|
|
#
|
|
|
|
|
# Copyright (C) 2014 Connor Abbott
|
|
|
|
|
#
|
|
|
|
|
# Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
# copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
# to deal in the Software without restriction, including without limitation
|
|
|
|
|
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
# and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
# Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
#
|
|
|
|
|
# The above copyright notice and this permission notice (including the next
|
|
|
|
|
# paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
# Software.
|
|
|
|
|
#
|
|
|
|
|
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
|
# IN THE SOFTWARE.
|
|
|
|
|
#
|
|
|
|
|
# Authors:
|
|
|
|
|
# Connor Abbott (cwabbott0@gmail.com)
|
|
|
|
|
|
2018-11-07 12:15:22 -06:00
|
|
|
from nir_opcodes import opcodes, type_sizes
|
nir: use Python to autogenerate opcode information
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it was difficult
to use nir_opcodes.h to do other things like autogenerate a builder API. Now, we
store opcode information in nir_opcodes.py, and we have nir_opcodes_c.py to
generate the old nir_opcodes.c and nir_opcodes_h.py to generate nir_opcodes.h,
which contains all the enum names and gets included into nir.h like before. In
addition to solving the above problems, using Python and Mako to generate
everything means that it's much easier to add keep information centralized as we
add new things like constant propagation that require per-opcode information.
v2:
- make Opcode derive from object (Dylan)
- don't use assert like it's a function (Dylan)
- style fixes for fnoise, use xrange (Dylan)
- use iterkeys() in nir_opcodes_h.py (Dylan)
- use pydoc-style comments (Jason)
- don't make fmin/fmax commutative and associative yet (Jason)
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v3 Jason Ekstrand <jason.ekstrand@intel.com>
- Alphabetize source file lists
- Generate nir_opcodes.h in the builddir instead of the source dir
- Include $(builddir)/src/glsl/nir in the i965 build
- Rework nir_opcodes.h generation so it generates a complete header file
instead of one that has to be embedded inside an enum declaration
2015-01-22 23:32:14 -05:00
|
|
|
from mako.template import Template
|
|
|
|
|
|
|
|
|
|
template = Template("""
|
|
|
|
|
#include "nir.h"
|
|
|
|
|
|
2017-03-07 19:54:37 -08:00
|
|
|
nir_op
|
2017-07-01 07:58:26 +02:00
|
|
|
nir_type_conversion_op(nir_alu_type src, nir_alu_type dst, nir_rounding_mode rnd)
|
2017-03-07 19:54:37 -08:00
|
|
|
{
|
|
|
|
|
nir_alu_type src_base = (nir_alu_type) nir_alu_type_get_base_type(src);
|
|
|
|
|
nir_alu_type dst_base = (nir_alu_type) nir_alu_type_get_base_type(dst);
|
|
|
|
|
unsigned src_bit_size = nir_alu_type_get_type_size(src);
|
|
|
|
|
unsigned dst_bit_size = nir_alu_type_get_type_size(dst);
|
|
|
|
|
|
|
|
|
|
if (src == dst && src_base == nir_type_float) {
|
2019-05-06 11:45:46 -05:00
|
|
|
return nir_op_mov;
|
2018-11-07 13:43:40 -06:00
|
|
|
} else if (src == dst && src_base == nir_type_bool) {
|
2019-05-06 11:45:46 -05:00
|
|
|
return nir_op_mov;
|
2017-03-07 19:54:37 -08:00
|
|
|
} else if ((src_base == nir_type_int || src_base == nir_type_uint) &&
|
|
|
|
|
(dst_base == nir_type_int || dst_base == nir_type_uint) &&
|
|
|
|
|
src_bit_size == dst_bit_size) {
|
|
|
|
|
/* Integer <-> integer conversions with the same bit-size on both
|
|
|
|
|
* ends are just no-op moves.
|
|
|
|
|
*/
|
2019-05-06 11:45:46 -05:00
|
|
|
return nir_op_mov;
|
2017-03-07 19:54:37 -08:00
|
|
|
}
|
|
|
|
|
|
2022-02-22 10:22:12 -08:00
|
|
|
/* f2b, i2b, and u2b do not exist. Use ine or fne (via nir_type_conversion)
|
|
|
|
|
* instead.
|
|
|
|
|
*/
|
|
|
|
|
assert(src_base == dst_base || dst_base != nir_type_bool);
|
nir: Eliminate nir_op_i2b
There are a lot of optimizations in opt_algebraic that match ('ine', a,
0), but there are almost none that match i2b. Instead of adding a huge
pile of additional patterns (including variations that include both ine
and i2b), always lower i2b to a != 0.
At this point in the series, it should be impossible for anything to
generate i2b, so there /should not/ be any changes.
The failing test on d3d12 is a pre-existing bug that is triggered by
this change. I talked to Jesse about it, and, after some analysis, he
suggested just adding it to the list of known failures.
v2: Don't rematerialize i2b instructions in dxil_nir_lower_x2b.
v3: Don't rematerialize i2b instructions in zink_nir_algebraic.py.
v4: Fix zink-on-TGL CI failures by calling nir_opt_algebraic after
nir_lower_doubles makes progress. The latter can generate b2i
instructions, but nir_lower_int64 can't handle them (anymore).
v5: Add back most of the hunk at line 2125 of nir_opt_algebraic.py. I
had accidentally removed the f2b(bf2(x)) optimization.
v6: Just eliminate the i2b instruction.
v7: Remove missed i2b32 in midgard_compile.c. Remove (now unused)
emit_alu_i2orf2_b1 function from sfn_instr_alu.cpp. Previously this
function was still used. :shrug:
No shader-db changes on any Intel platform.
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141165875 -> 141165873 (-0.0%)
Instructions helped: 2
Cycles in all programs: 9098956382 -> 9098956350 (-0.0%)
Cycles helped: 2
The two Vulkan shaders are helped because of the "new" (('b2i32',
('ine', ('ubfe', a, b, 1), 0)), ('ubfe', a, b, 1)) algebraic pattern.
Acked-by: Jesse Natalie <jenatali@microsoft.com> [earlier version]
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev> [earlier version]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
2022-02-15 09:35:47 -08:00
|
|
|
|
2017-03-07 19:54:37 -08:00
|
|
|
switch (src_base) {
|
2018-11-07 13:43:40 -06:00
|
|
|
% for src_t in ['int', 'uint', 'float', 'bool']:
|
2017-03-07 19:54:37 -08:00
|
|
|
case nir_type_${src_t}:
|
|
|
|
|
switch (dst_base) {
|
2018-11-07 13:43:40 -06:00
|
|
|
% for dst_t in ['int', 'uint', 'float', 'bool']:
|
2017-03-07 19:54:37 -08:00
|
|
|
case nir_type_${dst_t}:
|
|
|
|
|
% if src_t in ['int', 'uint'] and dst_t in ['int', 'uint']:
|
|
|
|
|
% if dst_t == 'int':
|
|
|
|
|
<% continue %>
|
|
|
|
|
% else:
|
|
|
|
|
<% dst_t = src_t %>
|
|
|
|
|
% endif
|
2018-11-07 13:43:40 -06:00
|
|
|
% elif src_t == 'bool' and dst_t in ['int', 'uint', 'bool']:
|
|
|
|
|
% if dst_t == 'int':
|
|
|
|
|
<% continue %>
|
|
|
|
|
% else:
|
|
|
|
|
<% dst_t = 'int' %>
|
|
|
|
|
% endif
|
2022-02-22 10:22:12 -08:00
|
|
|
% elif src_t != 'bool' and dst_t == 'bool':
|
nir: Eliminate nir_op_i2b
There are a lot of optimizations in opt_algebraic that match ('ine', a,
0), but there are almost none that match i2b. Instead of adding a huge
pile of additional patterns (including variations that include both ine
and i2b), always lower i2b to a != 0.
At this point in the series, it should be impossible for anything to
generate i2b, so there /should not/ be any changes.
The failing test on d3d12 is a pre-existing bug that is triggered by
this change. I talked to Jesse about it, and, after some analysis, he
suggested just adding it to the list of known failures.
v2: Don't rematerialize i2b instructions in dxil_nir_lower_x2b.
v3: Don't rematerialize i2b instructions in zink_nir_algebraic.py.
v4: Fix zink-on-TGL CI failures by calling nir_opt_algebraic after
nir_lower_doubles makes progress. The latter can generate b2i
instructions, but nir_lower_int64 can't handle them (anymore).
v5: Add back most of the hunk at line 2125 of nir_opt_algebraic.py. I
had accidentally removed the f2b(bf2(x)) optimization.
v6: Just eliminate the i2b instruction.
v7: Remove missed i2b32 in midgard_compile.c. Remove (now unused)
emit_alu_i2orf2_b1 function from sfn_instr_alu.cpp. Previously this
function was still used. :shrug:
No shader-db changes on any Intel platform.
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141165875 -> 141165873 (-0.0%)
Instructions helped: 2
Cycles in all programs: 9098956382 -> 9098956350 (-0.0%)
Cycles helped: 2
The two Vulkan shaders are helped because of the "new" (('b2i32',
('ine', ('ubfe', a, b, 1), 0)), ('ubfe', a, b, 1)) algebraic pattern.
Acked-by: Jesse Natalie <jenatali@microsoft.com> [earlier version]
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev> [earlier version]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
2022-02-15 09:35:47 -08:00
|
|
|
<% continue %>
|
2017-03-07 19:54:37 -08:00
|
|
|
% endif
|
|
|
|
|
switch (dst_bit_size) {
|
2018-11-07 12:15:22 -06:00
|
|
|
% for dst_bits in type_sizes(dst_t):
|
2017-03-07 19:54:37 -08:00
|
|
|
case ${dst_bits}:
|
2017-07-01 07:58:26 +02:00
|
|
|
% if src_t == 'float' and dst_t == 'float' and dst_bits == 16:
|
|
|
|
|
switch(rnd) {
|
2018-04-26 21:06:08 +02:00
|
|
|
% for rnd_t in [('rtne', '_rtne'), ('rtz', '_rtz'), ('undef', '')]:
|
|
|
|
|
case nir_rounding_mode_${rnd_t[0]}:
|
|
|
|
|
return ${'nir_op_{0}2{1}{2}{3}'.format(src_t[0], dst_t[0],
|
|
|
|
|
dst_bits, rnd_t[1])};
|
2017-07-01 07:58:26 +02:00
|
|
|
% endfor
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Invalid 16-bit nir rounding mode");
|
|
|
|
|
}
|
|
|
|
|
% else:
|
|
|
|
|
assert(rnd == nir_rounding_mode_undef);
|
2017-03-17 16:21:38 -07:00
|
|
|
return ${'nir_op_{0}2{1}{2}'.format(src_t[0], dst_t[0], dst_bits)};
|
2017-07-01 07:58:26 +02:00
|
|
|
% endif
|
2017-03-07 19:54:37 -08:00
|
|
|
% endfor
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Invalid nir alu bit size");
|
|
|
|
|
}
|
|
|
|
|
% endfor
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Invalid nir alu base type");
|
|
|
|
|
}
|
|
|
|
|
% endfor
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Invalid nir alu base type");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
nir: use Python to autogenerate opcode information
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it was difficult
to use nir_opcodes.h to do other things like autogenerate a builder API. Now, we
store opcode information in nir_opcodes.py, and we have nir_opcodes_c.py to
generate the old nir_opcodes.c and nir_opcodes_h.py to generate nir_opcodes.h,
which contains all the enum names and gets included into nir.h like before. In
addition to solving the above problems, using Python and Mako to generate
everything means that it's much easier to add keep information centralized as we
add new things like constant propagation that require per-opcode information.
v2:
- make Opcode derive from object (Dylan)
- don't use assert like it's a function (Dylan)
- style fixes for fnoise, use xrange (Dylan)
- use iterkeys() in nir_opcodes_h.py (Dylan)
- use pydoc-style comments (Jason)
- don't make fmin/fmax commutative and associative yet (Jason)
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v3 Jason Ekstrand <jason.ekstrand@intel.com>
- Alphabetize source file lists
- Generate nir_opcodes.h in the builddir instead of the source dir
- Include $(builddir)/src/glsl/nir in the i965 build
- Rework nir_opcodes.h generation so it generates a complete header file
instead of one that has to be embedded inside an enum declaration
2015-01-22 23:32:14 -05:00
|
|
|
const nir_op_info nir_op_infos[nir_num_opcodes] = {
|
2018-07-06 12:20:26 +02:00
|
|
|
% for name, opcode in sorted(opcodes.items()):
|
nir: use Python to autogenerate opcode information
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it was difficult
to use nir_opcodes.h to do other things like autogenerate a builder API. Now, we
store opcode information in nir_opcodes.py, and we have nir_opcodes_c.py to
generate the old nir_opcodes.c and nir_opcodes_h.py to generate nir_opcodes.h,
which contains all the enum names and gets included into nir.h like before. In
addition to solving the above problems, using Python and Mako to generate
everything means that it's much easier to add keep information centralized as we
add new things like constant propagation that require per-opcode information.
v2:
- make Opcode derive from object (Dylan)
- don't use assert like it's a function (Dylan)
- style fixes for fnoise, use xrange (Dylan)
- use iterkeys() in nir_opcodes_h.py (Dylan)
- use pydoc-style comments (Jason)
- don't make fmin/fmax commutative and associative yet (Jason)
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v3 Jason Ekstrand <jason.ekstrand@intel.com>
- Alphabetize source file lists
- Generate nir_opcodes.h in the builddir instead of the source dir
- Include $(builddir)/src/glsl/nir in the i965 build
- Rework nir_opcodes.h generation so it generates a complete header file
instead of one that has to be embedded inside an enum declaration
2015-01-22 23:32:14 -05:00
|
|
|
{
|
|
|
|
|
.name = "${name}",
|
|
|
|
|
.num_inputs = ${opcode.num_inputs},
|
|
|
|
|
.output_size = ${opcode.output_size},
|
|
|
|
|
.output_type = ${"nir_type_" + opcode.output_type},
|
|
|
|
|
.input_sizes = {
|
|
|
|
|
${ ", ".join(str(size) for size in opcode.input_sizes) }
|
|
|
|
|
},
|
|
|
|
|
.input_types = {
|
|
|
|
|
${ ", ".join("nir_type_" + type for type in opcode.input_types) }
|
|
|
|
|
},
|
2019-02-12 12:55:28 +01:00
|
|
|
.is_conversion = ${"true" if opcode.is_conversion else "false"},
|
nir: use Python to autogenerate opcode information
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it was difficult
to use nir_opcodes.h to do other things like autogenerate a builder API. Now, we
store opcode information in nir_opcodes.py, and we have nir_opcodes_c.py to
generate the old nir_opcodes.c and nir_opcodes_h.py to generate nir_opcodes.h,
which contains all the enum names and gets included into nir.h like before. In
addition to solving the above problems, using Python and Mako to generate
everything means that it's much easier to add keep information centralized as we
add new things like constant propagation that require per-opcode information.
v2:
- make Opcode derive from object (Dylan)
- don't use assert like it's a function (Dylan)
- style fixes for fnoise, use xrange (Dylan)
- use iterkeys() in nir_opcodes_h.py (Dylan)
- use pydoc-style comments (Jason)
- don't make fmin/fmax commutative and associative yet (Jason)
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v3 Jason Ekstrand <jason.ekstrand@intel.com>
- Alphabetize source file lists
- Generate nir_opcodes.h in the builddir instead of the source dir
- Include $(builddir)/src/glsl/nir in the i965 build
- Rework nir_opcodes.h generation so it generates a complete header file
instead of one that has to be embedded inside an enum declaration
2015-01-22 23:32:14 -05:00
|
|
|
.algebraic_properties =
|
|
|
|
|
${ "0" if opcode.algebraic_properties == "" else " | ".join(
|
|
|
|
|
"NIR_OP_IS_" + prop.upper() for prop in
|
|
|
|
|
opcode.algebraic_properties.strip().split(" ")) }
|
|
|
|
|
},
|
|
|
|
|
% endfor
|
|
|
|
|
};
|
|
|
|
|
""")
|
|
|
|
|
|
2018-11-07 12:15:22 -06:00
|
|
|
print(template.render(opcodes=opcodes, type_sizes=type_sizes))
|