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-23 04:32:14 +00:00
|
|
|
#! /usr/bin/env python
|
|
|
|
#
|
|
|
|
# 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)
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
|
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-23 04:32:14 +00:00
|
|
|
# Class that represents all the information we have about the opcode
|
|
|
|
# NOTE: this must be kept in sync with nir_op_info
|
|
|
|
|
|
|
|
class Opcode(object):
|
|
|
|
"""Class that represents all the information we have about the opcode
|
|
|
|
NOTE: this must be kept in sync with nir_op_info
|
|
|
|
"""
|
|
|
|
def __init__(self, name, output_size, output_type, input_sizes,
|
2015-01-23 21:38:46 +00:00
|
|
|
input_types, algebraic_properties, const_expr):
|
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-23 04:32:14 +00:00
|
|
|
"""Parameters:
|
|
|
|
|
|
|
|
- name is the name of the opcode (prepend nir_op_ for the enum name)
|
|
|
|
- all types are strings that get nir_type_ prepended to them
|
|
|
|
- input_types is a list of types
|
|
|
|
- algebraic_properties is a space-seperated string, where nir_op_is_ is
|
|
|
|
prepended before each entry
|
2015-01-23 21:38:46 +00:00
|
|
|
- const_expr is an expression or series of statements that computes the
|
|
|
|
constant value of the opcode given the constant values of its inputs.
|
|
|
|
|
|
|
|
Constant expressions are formed from the variables src0, src1, ...,
|
|
|
|
src(N-1), where N is the number of arguments. The output of the
|
|
|
|
expression should be stored in the dst variable. Per-component input
|
|
|
|
and output variables will be scalars and non-per-component input and
|
|
|
|
output variables will be a struct with fields named x, y, z, and w
|
|
|
|
all of the correct type. Input and output variables can be assumed
|
|
|
|
to already be of the correct type and need no conversion. In
|
|
|
|
particular, the conversion from the C bool type to/from NIR_TRUE and
|
|
|
|
NIR_FALSE happens automatically.
|
|
|
|
|
|
|
|
For per-component instructions, the entire expression will be
|
|
|
|
executed once for each component. For non-per-component
|
|
|
|
instructions, the expression is expected to store the correct values
|
|
|
|
in dst.x, dst.y, etc. If "dst" does not exist anywhere in the
|
|
|
|
constant expression, an assignment to dst will happen automatically
|
|
|
|
and the result will be equivalent to "dst = <expression>" for
|
|
|
|
per-component instructions and "dst.x = dst.y = ... = <expression>"
|
|
|
|
for non-per-component instructions.
|
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-23 04:32:14 +00:00
|
|
|
"""
|
|
|
|
assert isinstance(name, str)
|
|
|
|
assert isinstance(output_size, int)
|
|
|
|
assert isinstance(output_type, str)
|
|
|
|
assert isinstance(input_sizes, list)
|
|
|
|
assert isinstance(input_sizes[0], int)
|
|
|
|
assert isinstance(input_types, list)
|
|
|
|
assert isinstance(input_types[0], str)
|
|
|
|
assert isinstance(algebraic_properties, str)
|
2015-01-23 21:38:46 +00:00
|
|
|
assert isinstance(const_expr, str)
|
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-23 04:32:14 +00:00
|
|
|
assert len(input_sizes) == len(input_types)
|
|
|
|
assert 0 <= output_size <= 4
|
|
|
|
for size in input_sizes:
|
|
|
|
assert 0 <= size <= 4
|
|
|
|
if output_size != 0:
|
|
|
|
assert size != 0
|
|
|
|
self.name = name
|
|
|
|
self.num_inputs = len(input_sizes)
|
|
|
|
self.output_size = output_size
|
|
|
|
self.output_type = output_type
|
|
|
|
self.input_sizes = input_sizes
|
|
|
|
self.input_types = input_types
|
|
|
|
self.algebraic_properties = algebraic_properties
|
2015-01-23 21:38:46 +00:00
|
|
|
self.const_expr = const_expr
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# helper variables for strings
|
|
|
|
tfloat = "float"
|
|
|
|
tint = "int"
|
2015-08-14 18:45:06 +01:00
|
|
|
tbool = "bool32"
|
2015-05-15 17:14:47 +01:00
|
|
|
tuint = "uint"
|
2015-08-14 18:45:06 +01:00
|
|
|
tfloat32 = "float32"
|
|
|
|
tint32 = "int32"
|
|
|
|
tuint32 = "uint32"
|
2015-08-14 20:20:37 +01:00
|
|
|
tuint64 = "uint64"
|
2015-08-14 18:45:06 +01:00
|
|
|
tfloat64 = "float64"
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
commutative = "commutative "
|
|
|
|
associative = "associative "
|
|
|
|
|
|
|
|
# global dictionary of opcodes
|
|
|
|
opcodes = {}
|
|
|
|
|
|
|
|
def opcode(name, output_size, output_type, input_sizes, input_types,
|
2015-01-23 21:38:46 +00:00
|
|
|
algebraic_properties, const_expr):
|
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-23 04:32:14 +00:00
|
|
|
assert name not in opcodes
|
|
|
|
opcodes[name] = Opcode(name, output_size, output_type, input_sizes,
|
2015-01-23 21:38:46 +00:00
|
|
|
input_types, algebraic_properties, const_expr)
|
|
|
|
|
2016-01-21 17:54:19 +00:00
|
|
|
def unop_convert(name, out_type, in_type, const_expr):
|
2015-01-23 21:38:46 +00:00
|
|
|
opcode(name, 0, out_type, [0], [in_type], "", const_expr)
|
|
|
|
|
|
|
|
def unop(name, ty, const_expr):
|
|
|
|
opcode(name, 0, ty, [0], [ty], "", const_expr)
|
|
|
|
|
|
|
|
def unop_horiz(name, output_size, output_type, input_size, input_type,
|
|
|
|
const_expr):
|
|
|
|
opcode(name, output_size, output_type, [input_size], [input_type], "",
|
|
|
|
const_expr)
|
|
|
|
|
|
|
|
def unop_reduce(name, output_size, output_type, input_type, prereduce_expr,
|
|
|
|
reduce_expr, final_expr):
|
|
|
|
def prereduce(src):
|
|
|
|
return "(" + prereduce_expr.format(src=src) + ")"
|
|
|
|
def final(src):
|
|
|
|
return final_expr.format(src="(" + src + ")")
|
|
|
|
def reduce_(src0, src1):
|
|
|
|
return reduce_expr.format(src0=src0, src1=src1)
|
|
|
|
src0 = prereduce("src0.x")
|
|
|
|
src1 = prereduce("src0.y")
|
|
|
|
src2 = prereduce("src0.z")
|
|
|
|
src3 = prereduce("src0.w")
|
|
|
|
unop_horiz(name + "2", output_size, output_type, 2, input_type,
|
|
|
|
final(reduce_(src0, src1)))
|
|
|
|
unop_horiz(name + "3", output_size, output_type, 3, input_type,
|
|
|
|
final(reduce_(reduce_(src0, src1), src2)))
|
|
|
|
unop_horiz(name + "4", output_size, output_type, 4, input_type,
|
|
|
|
final(reduce_(reduce_(src0, src1), reduce_(src2, src3))))
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
# These two move instructions differ in what modifiers they support and what
|
|
|
|
# the negate modifier means. Otherwise, they are identical.
|
2015-01-23 21:38:46 +00:00
|
|
|
unop("fmov", tfloat, "src0")
|
|
|
|
unop("imov", tint, "src0")
|
|
|
|
|
|
|
|
unop("ineg", tint, "-src0")
|
|
|
|
unop("fneg", tfloat, "-src0")
|
|
|
|
unop("inot", tint, "~src0") # invert every bit of the integer
|
|
|
|
unop("fnot", tfloat, "(src0 == 0.0f) ? 1.0f : 0.0f")
|
|
|
|
unop("fsign", tfloat, "(src0 == 0.0f) ? 0.0f : ((src0 > 0.0f) ? 1.0f : -1.0f)")
|
|
|
|
unop("isign", tint, "(src0 == 0) ? 0 : ((src0 > 0) ? 1 : -1)")
|
2015-01-26 17:40:25 +00:00
|
|
|
unop("iabs", tint, "(src0 < 0) ? -src0 : src0")
|
2015-01-23 21:38:46 +00:00
|
|
|
unop("fabs", tfloat, "fabsf(src0)")
|
|
|
|
unop("fsat", tfloat, "(src0 > 1.0f) ? 1.0f : ((src0 <= 0.0f) ? 0.0f : src0)")
|
|
|
|
unop("frcp", tfloat, "1.0f / src0")
|
|
|
|
unop("frsq", tfloat, "1.0f / sqrtf(src0)")
|
|
|
|
unop("fsqrt", tfloat, "sqrtf(src0)")
|
|
|
|
unop("fexp2", tfloat, "exp2f(src0)")
|
|
|
|
unop("flog2", tfloat, "log2f(src0)")
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("f2i", tint32, tfloat32, "src0") # Float-to-integer conversion.
|
|
|
|
unop_convert("f2u", tuint32, tfloat32, "src0") # Float-to-unsigned conversion
|
2016-01-12 11:39:58 +00:00
|
|
|
unop_convert("d2i", tint32, tfloat64, "src0") # Double-to-integer conversion.
|
|
|
|
unop_convert("d2u", tuint32, tfloat64, "src0") # Double-to-unsigned conversion.
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("i2f", tfloat32, tint32, "src0") # Integer-to-float conversion.
|
2016-01-12 13:03:08 +00:00
|
|
|
unop_convert("i2d", tfloat64, tint32, "src0") # Integer-to-double conversion.
|
2015-01-23 21:38:46 +00:00
|
|
|
# Float-to-boolean conversion
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("f2b", tbool, tfloat32, "src0 != 0.0f")
|
2016-01-12 11:39:58 +00:00
|
|
|
unop_convert("d2b", tbool, tfloat64, "src0 != 0.0")
|
2015-01-23 21:38:46 +00:00
|
|
|
# Boolean-to-float conversion
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("b2f", tfloat32, tbool, "src0 ? 1.0f : 0.0f")
|
2015-01-23 21:38:46 +00:00
|
|
|
# Int-to-boolean conversion
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("i2b", tbool, tint32, "src0 != 0")
|
|
|
|
unop_convert("b2i", tint32, tbool, "src0 ? 1 : 0") # Boolean-to-int conversion
|
|
|
|
unop_convert("u2f", tfloat32, tuint32, "src0") # Unsigned-to-float conversion.
|
2016-01-12 13:03:08 +00:00
|
|
|
unop_convert("u2d", tfloat64, tuint32, "src0") # Unsigned-to-double conversion.
|
2015-07-30 07:46:20 +01:00
|
|
|
# double-to-float conversion
|
|
|
|
unop_convert("d2f", tfloat32, tfloat64, "src0") # Single to double precision
|
|
|
|
unop_convert("f2d", tfloat64, tfloat32, "src0") # Double to single precision
|
2015-01-23 21:38:46 +00:00
|
|
|
|
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-23 04:32:14 +00:00
|
|
|
# Unary floating-point rounding operations.
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("ftrunc", tfloat, "bit_size == 64 ? trunc(src0) : truncf(src0)")
|
|
|
|
unop("fceil", tfloat, "bit_size == 64 ? ceil(src0) : ceilf(src0)")
|
|
|
|
unop("ffloor", tfloat, "bit_size == 64 ? floor(src0) : floorf(src0)")
|
|
|
|
unop("ffract", tfloat, "src0 - (bit_size == 64 ? floor(src0) : floorf(src0))")
|
|
|
|
unop("fround_even", tfloat, "bit_size == 64 ? _mesa_roundeven(src0) : _mesa_roundevenf(src0)")
|
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-23 04:32:14 +00:00
|
|
|
|
2016-03-25 20:58:17 +00:00
|
|
|
unop("fquantize2f16", tfloat, "(fabs(src0) < ldexpf(1.0, -14)) ? copysignf(0.0f, src0) : _mesa_half_to_float(_mesa_float_to_half(src0))")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# Trigonometric operations.
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("fsin", tfloat, "bit_size == 64 ? sin(src0) : sinf(src0)")
|
|
|
|
unop("fcos", tfloat, "bit_size == 64 ? cos(src0) : cosf(src0)")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
# Partial derivatives.
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("fddx", tfloat, "0.0") # the derivative of a constant is 0.
|
|
|
|
unop("fddy", tfloat, "0.0")
|
|
|
|
unop("fddx_fine", tfloat, "0.0")
|
|
|
|
unop("fddy_fine", tfloat, "0.0")
|
|
|
|
unop("fddx_coarse", tfloat, "0.0")
|
|
|
|
unop("fddy_coarse", tfloat, "0.0")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
# Floating point pack and unpack operations.
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def pack_2x16(fmt):
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("pack_" + fmt + "_2x16", 1, tuint32, 2, tfloat32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst.x = (uint32_t) pack_fmt_1x16(src0.x);
|
|
|
|
dst.x |= ((uint32_t) pack_fmt_1x16(src0.y)) << 16;
|
|
|
|
""".replace("fmt", fmt))
|
|
|
|
|
|
|
|
def pack_4x8(fmt):
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("pack_" + fmt + "_4x8", 1, tuint32, 4, tfloat32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst.x = (uint32_t) pack_fmt_1x8(src0.x);
|
|
|
|
dst.x |= ((uint32_t) pack_fmt_1x8(src0.y)) << 8;
|
|
|
|
dst.x |= ((uint32_t) pack_fmt_1x8(src0.z)) << 16;
|
|
|
|
dst.x |= ((uint32_t) pack_fmt_1x8(src0.w)) << 24;
|
|
|
|
""".replace("fmt", fmt))
|
|
|
|
|
|
|
|
def unpack_2x16(fmt):
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("unpack_" + fmt + "_2x16", 2, tfloat32, 1, tuint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst.x = unpack_fmt_1x16((uint16_t)(src0.x & 0xffff));
|
|
|
|
dst.y = unpack_fmt_1x16((uint16_t)(src0.x << 16));
|
|
|
|
""".replace("fmt", fmt))
|
|
|
|
|
|
|
|
def unpack_4x8(fmt):
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("unpack_" + fmt + "_4x8", 4, tfloat32, 1, tuint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst.x = unpack_fmt_1x8((uint8_t)(src0.x & 0xff));
|
|
|
|
dst.y = unpack_fmt_1x8((uint8_t)((src0.x >> 8) & 0xff));
|
|
|
|
dst.z = unpack_fmt_1x8((uint8_t)((src0.x >> 16) & 0xff));
|
|
|
|
dst.w = unpack_fmt_1x8((uint8_t)(src0.x >> 24));
|
|
|
|
""".replace("fmt", fmt))
|
|
|
|
|
|
|
|
|
|
|
|
pack_2x16("snorm")
|
|
|
|
pack_4x8("snorm")
|
|
|
|
pack_2x16("unorm")
|
|
|
|
pack_4x8("unorm")
|
|
|
|
pack_2x16("half")
|
|
|
|
unpack_2x16("snorm")
|
|
|
|
unpack_4x8("snorm")
|
|
|
|
unpack_2x16("unorm")
|
|
|
|
unpack_4x8("unorm")
|
|
|
|
unpack_2x16("half")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("pack_uvec2_to_uint", 1, tuint32, 2, tuint32, """
|
2016-01-25 19:05:52 +00:00
|
|
|
dst.x = (src0.x & 0xffff) | (src0.y >> 16);
|
|
|
|
""")
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("pack_uvec4_to_uint", 1, tuint32, 4, tuint32, """
|
2016-01-25 19:05:52 +00:00
|
|
|
dst.x = (src0.x << 0) |
|
|
|
|
(src0.y << 8) |
|
|
|
|
(src0.z << 16) |
|
|
|
|
(src0.w << 24);
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-08-14 20:20:37 +01:00
|
|
|
unop_horiz("pack_double_2x32", 1, tuint64, 2, tuint32, """
|
|
|
|
union {
|
|
|
|
uint64_t u64;
|
|
|
|
struct {
|
|
|
|
uint32_t i1;
|
|
|
|
uint32_t i2;
|
|
|
|
};
|
|
|
|
} di;
|
|
|
|
|
|
|
|
di.i1 = src0.x;
|
|
|
|
di.i2 = src0.y;
|
|
|
|
dst.x = di.u64;
|
|
|
|
""")
|
|
|
|
|
|
|
|
unop_horiz("unpack_double_2x32", 2, tuint32, 1, tuint64, """
|
|
|
|
union {
|
|
|
|
uint64_t u64;
|
|
|
|
struct {
|
|
|
|
uint32_t i1;
|
|
|
|
uint32_t i2;
|
|
|
|
};
|
|
|
|
} di;
|
|
|
|
|
|
|
|
di.u64 = src0.x;
|
|
|
|
dst.x = di.i1;
|
|
|
|
dst.y = di.i2;
|
|
|
|
""")
|
|
|
|
|
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-23 04:32:14 +00:00
|
|
|
# Lowered floating point unpacking operations.
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("unpack_half_2x16_split_x", 1, tfloat32, 1, tuint32,
|
2015-01-26 17:36:58 +00:00
|
|
|
"unpack_half_1x16((uint16_t)(src0.x & 0xffff))")
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_horiz("unpack_half_2x16_split_y", 1, tfloat32, 1, tuint32,
|
2015-01-26 17:36:58 +00:00
|
|
|
"unpack_half_1x16((uint16_t)(src0.x >> 16))")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-08-07 16:37:38 +01:00
|
|
|
unop_convert("unpack_double_2x32_split_x", tuint32, tuint64, """
|
|
|
|
union {
|
|
|
|
uint64_t u64;
|
|
|
|
struct {
|
|
|
|
uint32_t x;
|
|
|
|
uint32_t y;
|
|
|
|
};
|
|
|
|
} di;
|
|
|
|
di.u64 = src0;
|
|
|
|
dst = di.x;
|
|
|
|
""")
|
|
|
|
|
|
|
|
unop_convert("unpack_double_2x32_split_y", tuint32, tuint64, """
|
|
|
|
union {
|
|
|
|
uint64_t u64;
|
|
|
|
struct {
|
|
|
|
uint32_t x;
|
|
|
|
uint32_t y;
|
|
|
|
};
|
|
|
|
} di;
|
|
|
|
di.u64 = src0;
|
|
|
|
dst = di.y;
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# Bit operations, part of ARB_gpu_shader5.
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("bitfield_reverse", tuint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
/* we're not winning any awards for speed here, but that's ok */
|
|
|
|
dst = 0;
|
|
|
|
for (unsigned bit = 0; bit < 32; bit++)
|
|
|
|
dst |= ((src0 >> bit) & 1) << (31 - bit);
|
|
|
|
""")
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("bit_count", tuint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst = 0;
|
|
|
|
for (unsigned bit = 0; bit < 32; bit++) {
|
|
|
|
if ((src0 >> bit) & 1)
|
|
|
|
dst++;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop_convert("ufind_msb", tint32, tuint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst = -1;
|
|
|
|
for (int bit = 31; bit > 0; bit--) {
|
|
|
|
if ((src0 >> bit) & 1) {
|
|
|
|
dst = bit;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("ifind_msb", tint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst = -1;
|
|
|
|
for (int bit = 31; bit >= 0; bit--) {
|
|
|
|
/* If src0 < 0, we're looking for the first 0 bit.
|
|
|
|
* if src0 >= 0, we're looking for the first 1 bit.
|
|
|
|
*/
|
|
|
|
if ((((src0 >> bit) & 1) && (src0 >= 0)) ||
|
|
|
|
(!((src0 >> bit) & 1) && (src0 < 0))) {
|
|
|
|
dst = bit;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
unop("find_lsb", tint32, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst = -1;
|
|
|
|
for (unsigned bit = 0; bit < 32; bit++) {
|
|
|
|
if ((src0 >> bit) & 1) {
|
|
|
|
dst = bit;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
for i in xrange(1, 5):
|
|
|
|
for j in xrange(1, 5):
|
2015-01-23 21:38:46 +00:00
|
|
|
unop_horiz("fnoise{0}_{1}".format(i, j), i, tfloat, j, tfloat, "0.0f")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def binop_convert(name, out_type, in_type, alg_props, const_expr):
|
|
|
|
opcode(name, 0, out_type, [0, 0], [in_type, in_type], alg_props, const_expr)
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def binop(name, ty, alg_props, const_expr):
|
|
|
|
binop_convert(name, ty, ty, alg_props, const_expr)
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def binop_compare(name, ty, alg_props, const_expr):
|
|
|
|
binop_convert(name, tbool, ty, alg_props, const_expr)
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
def binop_horiz(name, out_size, out_type, src1_size, src1_type, src2_size,
|
2015-01-23 21:38:46 +00:00
|
|
|
src2_type, const_expr):
|
|
|
|
opcode(name, out_size, out_type, [src1_size, src2_size], [src1_type, src2_type],
|
|
|
|
"", const_expr)
|
|
|
|
|
|
|
|
def binop_reduce(name, output_size, output_type, src_type, prereduce_expr,
|
|
|
|
reduce_expr, final_expr):
|
|
|
|
def final(src):
|
|
|
|
return final_expr.format(src= "(" + src + ")")
|
|
|
|
def reduce_(src0, src1):
|
|
|
|
return reduce_expr.format(src0=src0, src1=src1)
|
|
|
|
def prereduce(src0, src1):
|
|
|
|
return "(" + prereduce_expr.format(src0=src0, src1=src1) + ")"
|
|
|
|
src0 = prereduce("src0.x", "src1.x")
|
|
|
|
src1 = prereduce("src0.y", "src1.y")
|
|
|
|
src2 = prereduce("src0.z", "src1.z")
|
|
|
|
src3 = prereduce("src0.w", "src1.w")
|
|
|
|
opcode(name + "2", output_size, output_type,
|
|
|
|
[2, 2], [src_type, src_type], commutative,
|
|
|
|
final(reduce_(src0, src1)))
|
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-23 04:32:14 +00:00
|
|
|
opcode(name + "3", output_size, output_type,
|
2015-01-23 21:38:46 +00:00
|
|
|
[3, 3], [src_type, src_type], commutative,
|
|
|
|
final(reduce_(reduce_(src0, src1), src2)))
|
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-23 04:32:14 +00:00
|
|
|
opcode(name + "4", output_size, output_type,
|
2015-01-23 21:38:46 +00:00
|
|
|
[4, 4], [src_type, src_type], commutative,
|
|
|
|
final(reduce_(reduce_(src0, src1), reduce_(src2, src3))))
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fadd", tfloat, commutative + associative, "src0 + src1")
|
|
|
|
binop("iadd", tint, commutative + associative, "src0 + src1")
|
|
|
|
binop("fsub", tfloat, "", "src0 - src1")
|
|
|
|
binop("isub", tint, "", "src0 - src1")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fmul", tfloat, commutative + associative, "src0 * src1")
|
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-23 04:32:14 +00:00
|
|
|
# low 32-bits of signed/unsigned integer multiply
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("imul", tint, commutative + associative, "src0 * src1")
|
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-23 04:32:14 +00:00
|
|
|
# high 32-bits of signed integer multiply
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("imul_high", tint32, commutative,
|
2015-01-23 21:38:46 +00:00
|
|
|
"(int32_t)(((int64_t) src0 * (int64_t) src1) >> 32)")
|
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-23 04:32:14 +00:00
|
|
|
# high 32-bits of unsigned integer multiply
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("umul_high", tuint32, commutative,
|
2015-01-23 21:38:46 +00:00
|
|
|
"(uint32_t)(((uint64_t) src0 * (uint64_t) src1) >> 32)")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fdiv", tfloat, "", "src0 / src1")
|
|
|
|
binop("idiv", tint, "", "src0 / src1")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("udiv", tuint, "", "src0 / src1")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# returns a boolean representing the carry resulting from the addition of
|
|
|
|
# the two unsigned arguments.
|
|
|
|
|
2016-01-06 23:30:37 +00:00
|
|
|
binop_convert("uadd_carry", tuint, tuint, commutative, "src0 + src1 < src0")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# returns a boolean representing the borrow resulting from the subtraction
|
|
|
|
# of the two unsigned arguments.
|
|
|
|
|
2016-01-06 23:30:37 +00:00
|
|
|
binop_convert("usub_borrow", tuint, tuint, "", "src0 < src1")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fmod", tfloat, "", "src0 - src1 * floorf(src0 / src1)")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("umod", tuint, "", "src1 == 0 ? 0 : src0 % src1")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Comparisons
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
|
# these integer-aware comparisons return a boolean (0 or ~0)
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop_compare("flt", tfloat, "", "src0 < src1")
|
|
|
|
binop_compare("fge", tfloat, "", "src0 >= src1")
|
|
|
|
binop_compare("feq", tfloat, commutative, "src0 == src1")
|
|
|
|
binop_compare("fne", tfloat, commutative, "src0 != src1")
|
|
|
|
binop_compare("ilt", tint, "", "src0 < src1")
|
|
|
|
binop_compare("ige", tint, "", "src0 >= src1")
|
|
|
|
binop_compare("ieq", tint, commutative, "src0 == src1")
|
|
|
|
binop_compare("ine", tint, commutative, "src0 != src1")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop_compare("ult", tuint, "", "src0 < src1")
|
|
|
|
binop_compare("uge", tuint, "", "src0 >= src1")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# integer-aware GLSL-style comparisons that compare floats and ints
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop_reduce("ball_fequal", 1, tbool, tfloat, "{src0} == {src1}",
|
|
|
|
"{src0} && {src1}", "{src}")
|
|
|
|
binop_reduce("bany_fnequal", 1, tbool, tfloat, "{src0} != {src1}",
|
|
|
|
"{src0} || {src1}", "{src}")
|
|
|
|
binop_reduce("ball_iequal", 1, tbool, tint, "{src0} == {src1}",
|
|
|
|
"{src0} && {src1}", "{src}")
|
|
|
|
binop_reduce("bany_inequal", 1, tbool, tint, "{src0} != {src1}",
|
|
|
|
"{src0} || {src1}", "{src}")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# non-integer-aware GLSL-style comparisons that return 0.0 or 1.0
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
binop_reduce("fall_equal", 1, tfloat32, tfloat32, "{src0} == {src1}",
|
2015-01-23 21:38:46 +00:00
|
|
|
"{src0} && {src1}", "{src} ? 1.0f : 0.0f")
|
2015-08-14 18:45:06 +01:00
|
|
|
binop_reduce("fany_nequal", 1, tfloat32, tfloat32, "{src0} != {src1}",
|
2015-01-23 21:38:46 +00:00
|
|
|
"{src0} || {src1}", "{src} ? 1.0f : 0.0f")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# These comparisons for integer-less hardware return 1.0 and 0.0 for true
|
|
|
|
# and false respectively
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("slt", tfloat32, "", "(src0 < src1) ? 1.0f : 0.0f") # Set on Less Than
|
|
|
|
binop("sge", tfloat32, "", "(src0 >= src1) ? 1.0f : 0.0f") # Set on Greater or Equal
|
|
|
|
binop("seq", tfloat32, commutative, "(src0 == src1) ? 1.0f : 0.0f") # Set on Equal
|
|
|
|
binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") # Set on Not Equal
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("ishl", tint, "", "src0 << src1")
|
|
|
|
binop("ishr", tint, "", "src0 >> src1")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("ushr", tuint, "", "src0 >> src1")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# bitwise logic operators
|
|
|
|
#
|
|
|
|
# These are also used as boolean and, or, xor for hardware supporting
|
|
|
|
# integers.
|
|
|
|
|
|
|
|
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("iand", tuint, commutative + associative, "src0 & src1")
|
|
|
|
binop("ior", tuint, commutative + associative, "src0 | src1")
|
|
|
|
binop("ixor", tuint, commutative + associative, "src0 ^ src1")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
# floating point logic operators
|
|
|
|
#
|
|
|
|
# These use (src != 0.0) for testing the truth of the input, and output 1.0
|
|
|
|
# for true and 0.0 for false
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("fand", tfloat32, commutative,
|
2015-01-23 21:38:46 +00:00
|
|
|
"((src0 != 0.0f) && (src1 != 0.0f)) ? 1.0f : 0.0f")
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("for", tfloat32, commutative,
|
2015-01-23 21:38:46 +00:00
|
|
|
"((src0 != 0.0f) || (src1 != 0.0f)) ? 1.0f : 0.0f")
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("fxor", tfloat32, commutative,
|
2015-01-23 21:38:46 +00:00
|
|
|
"(src0 != 0.0f && src1 == 0.0f) || (src0 == 0.0f && src1 != 0.0f) ? 1.0f : 0.0f")
|
|
|
|
|
|
|
|
binop_reduce("fdot", 1, tfloat, tfloat, "{src0} * {src1}", "{src0} + {src1}",
|
|
|
|
"{src}")
|
|
|
|
|
2015-09-10 18:51:46 +01:00
|
|
|
binop_reduce("fdot_replicated", 4, tfloat, tfloat,
|
|
|
|
"{src0} * {src1}", "{src0} + {src1}", "{src}")
|
|
|
|
|
2015-09-23 00:54:27 +01:00
|
|
|
opcode("fdph", 1, tfloat, [3, 4], [tfloat, tfloat], "",
|
|
|
|
"src0.x * src1.x + src0.y * src1.y + src0.z * src1.z + src1.w")
|
|
|
|
opcode("fdph_replicated", 4, tfloat, [3, 4], [tfloat, tfloat], "",
|
|
|
|
"src0.x * src1.x + src0.y * src1.y + src0.z * src1.z + src1.w")
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fmin", tfloat, "", "fminf(src0, src1)")
|
|
|
|
binop("imin", tint, commutative + associative, "src1 > src0 ? src0 : src1")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("umin", tuint, commutative + associative, "src1 > src0 ? src0 : src1")
|
2015-01-23 21:38:46 +00:00
|
|
|
binop("fmax", tfloat, "", "fmaxf(src0, src1)")
|
|
|
|
binop("imax", tint, commutative + associative, "src1 > src0 ? src1 : src0")
|
2015-05-15 17:14:47 +01:00
|
|
|
binop("umax", tuint, commutative + associative, "src1 > src0 ? src1 : src0")
|
2015-01-23 21:38:46 +00:00
|
|
|
|
2015-08-19 06:38:34 +01:00
|
|
|
# Saturated vector add for 4 8bit ints.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("usadd_4x8", tint32, commutative + associative, """
|
2015-08-19 06:38:34 +01:00
|
|
|
dst = 0;
|
|
|
|
for (int i = 0; i < 32; i += 8) {
|
|
|
|
dst |= MIN2(((src0 >> i) & 0xff) + ((src1 >> i) & 0xff), 0xff) << i;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
# Saturated vector subtract for 4 8bit ints.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("ussub_4x8", tint32, "", """
|
2015-08-19 06:38:34 +01:00
|
|
|
dst = 0;
|
|
|
|
for (int i = 0; i < 32; i += 8) {
|
|
|
|
int src0_chan = (src0 >> i) & 0xff;
|
|
|
|
int src1_chan = (src1 >> i) & 0xff;
|
|
|
|
if (src0_chan > src1_chan)
|
|
|
|
dst |= (src0_chan - src1_chan) << i;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
# vector min for 4 8bit ints.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("umin_4x8", tint32, commutative + associative, """
|
2015-08-19 06:38:34 +01:00
|
|
|
dst = 0;
|
|
|
|
for (int i = 0; i < 32; i += 8) {
|
|
|
|
dst |= MIN2((src0 >> i) & 0xff, (src1 >> i) & 0xff) << i;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
# vector max for 4 8bit ints.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("umax_4x8", tint32, commutative + associative, """
|
2015-08-19 06:38:34 +01:00
|
|
|
dst = 0;
|
|
|
|
for (int i = 0; i < 32; i += 8) {
|
|
|
|
dst |= MAX2((src0 >> i) & 0xff, (src1 >> i) & 0xff) << i;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
# unorm multiply: (a * b) / 255.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("umul_unorm_4x8", tint32, commutative + associative, """
|
2015-08-19 06:38:34 +01:00
|
|
|
dst = 0;
|
|
|
|
for (int i = 0; i < 32; i += 8) {
|
|
|
|
int src0_chan = (src0 >> i) & 0xff;
|
|
|
|
int src1_chan = (src1 >> i) & 0xff;
|
|
|
|
dst |= ((src0_chan * src1_chan) / 255) << i;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
binop("fpow", tfloat, "", "bit_size == 64 ? powf(src0, src1) : pow(src0, src1)")
|
2015-01-23 21:38:46 +00:00
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
binop_horiz("pack_half_2x16_split", 1, tuint32, 1, tfloat32, 1, tfloat32,
|
2015-01-23 21:38:46 +00:00
|
|
|
"pack_half_1x16(src0.x) | (pack_half_1x16(src1.x) << 16)")
|
|
|
|
|
2015-08-07 16:37:38 +01:00
|
|
|
binop_convert("pack_double_2x32_split", tuint64, tuint32, "", """
|
|
|
|
union {
|
|
|
|
uint64_t u64;
|
|
|
|
struct {
|
|
|
|
uint32_t x;
|
|
|
|
uint32_t y;
|
|
|
|
};
|
|
|
|
} di;
|
|
|
|
di.x = src0;
|
|
|
|
di.y = src1;
|
|
|
|
dst = di.u64;
|
|
|
|
""")
|
|
|
|
|
2016-01-08 00:16:35 +00:00
|
|
|
# bfm implements the behavior of the first operation of the SM5 "bfi" assembly
|
|
|
|
# and that of the "bfi1" i965 instruction. That is, it has undefined behavior
|
|
|
|
# if either of its arguments are 32.
|
2015-08-14 18:45:06 +01:00
|
|
|
binop_convert("bfm", tuint32, tint32, "", """
|
2016-01-11 20:13:24 +00:00
|
|
|
int bits = src0, offset = src1;
|
2016-01-08 00:16:35 +00:00
|
|
|
if (offset < 0 || bits < 0 || offset > 31 || bits > 31 || offset + bits > 32)
|
|
|
|
dst = 0; /* undefined */
|
2015-01-23 21:38:46 +00:00
|
|
|
else
|
2016-01-08 00:16:35 +00:00
|
|
|
dst = ((1u << bits) - 1) << offset;
|
2015-01-23 21:38:46 +00:00
|
|
|
""")
|
|
|
|
|
2015-01-28 20:43:47 +00:00
|
|
|
opcode("ldexp", 0, tfloat, [0, 0], [tfloat, tint], "", """
|
2015-08-14 18:45:06 +01:00
|
|
|
dst = (bit_size == 64) ? ldexp(src0, src1) : ldexpf(src0, src1);
|
2015-01-23 21:38:46 +00:00
|
|
|
/* flush denormals to zero. */
|
2015-01-28 20:41:44 +00:00
|
|
|
if (!isnormal(dst))
|
2015-07-12 20:37:00 +01:00
|
|
|
dst = copysignf(0.0f, src0);
|
2015-01-23 21:38:46 +00:00
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# Combines the first component of each input to make a 2-component vector.
|
|
|
|
|
2015-05-15 17:14:47 +01:00
|
|
|
binop_horiz("vec2", 2, tuint, 1, tuint, 1, tuint, """
|
2015-01-23 21:38:46 +00:00
|
|
|
dst.x = src0.x;
|
|
|
|
dst.y = src1.x;
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
2016-01-21 17:09:29 +00:00
|
|
|
# Byte extraction
|
|
|
|
binop("extract_u8", tuint, "", "(uint8_t)(src0 >> (src1 * 8))")
|
|
|
|
binop("extract_i8", tint, "", "(int8_t)(src0 >> (src1 * 8))")
|
|
|
|
|
|
|
|
# Word extraction
|
|
|
|
binop("extract_u16", tuint, "", "(uint16_t)(src0 >> (src1 * 16))")
|
|
|
|
binop("extract_i16", tint, "", "(int16_t)(src0 >> (src1 * 16))")
|
|
|
|
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def triop(name, ty, const_expr):
|
|
|
|
opcode(name, 0, ty, [0, 0, 0], [ty, ty, ty], "", const_expr)
|
|
|
|
def triop_horiz(name, output_size, src1_size, src2_size, src3_size, const_expr):
|
2015-05-15 17:14:47 +01:00
|
|
|
opcode(name, output_size, tuint,
|
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-23 04:32:14 +00:00
|
|
|
[src1_size, src2_size, src3_size],
|
2015-05-15 17:14:47 +01:00
|
|
|
[tuint, tuint, tuint], "", const_expr)
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
triop("ffma", tfloat, "src0 * src1 + src2")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
triop("flrp", tfloat, "src0 * (1 - src2) + src1 * src2")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# Conditional Select
|
|
|
|
#
|
|
|
|
# A vector conditional select instruction (like ?:, but operating per-
|
|
|
|
# component on vectors). There are two versions, one for floating point
|
|
|
|
# bools (0.0 vs 1.0) and one for integer bools (0 vs ~0).
|
|
|
|
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
triop("fcsel", tfloat32, "(src0 != 0.0f) ? src1 : src2")
|
2015-05-15 17:14:47 +01:00
|
|
|
opcode("bcsel", 0, tuint, [0, 0, 0],
|
|
|
|
[tbool, tuint, tuint], "", "src0 ? src1 : src2")
|
2015-01-23 21:38:46 +00:00
|
|
|
|
2016-01-13 19:08:37 +00:00
|
|
|
# SM5 bfi assembly
|
2015-08-14 18:45:06 +01:00
|
|
|
triop("bfi", tuint32, """
|
2015-08-04 22:04:34 +01:00
|
|
|
unsigned mask = src0, insert = src1, base = src2;
|
2015-01-23 21:38:46 +00:00
|
|
|
if (mask == 0) {
|
|
|
|
dst = base;
|
|
|
|
} else {
|
|
|
|
unsigned tmp = mask;
|
|
|
|
while (!(tmp & 1)) {
|
|
|
|
tmp >>= 1;
|
|
|
|
insert <<= 1;
|
|
|
|
}
|
2015-08-04 22:04:34 +01:00
|
|
|
dst = (base & ~mask) | (insert & mask);
|
2015-01-23 21:38:46 +00:00
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
2016-01-13 19:09:11 +00:00
|
|
|
# SM5 ubfe/ibfe assembly
|
2015-08-14 18:45:06 +01:00
|
|
|
opcode("ubfe", 0, tuint32,
|
|
|
|
[0, 0, 0], [tuint32, tint32, tint32], "", """
|
2016-01-13 19:09:11 +00:00
|
|
|
unsigned base = src0;
|
|
|
|
int offset = src1, bits = src2;
|
|
|
|
if (bits == 0) {
|
|
|
|
dst = 0;
|
|
|
|
} else if (bits < 0 || offset < 0) {
|
|
|
|
dst = 0; /* undefined */
|
|
|
|
} else if (offset + bits < 32) {
|
|
|
|
dst = (base << (32 - bits - offset)) >> (32 - bits);
|
|
|
|
} else {
|
|
|
|
dst = base >> offset;
|
|
|
|
}
|
|
|
|
""")
|
2015-08-14 18:45:06 +01:00
|
|
|
opcode("ibfe", 0, tint32,
|
|
|
|
[0, 0, 0], [tint32, tint32, tint32], "", """
|
2016-01-13 19:09:11 +00:00
|
|
|
int base = src0;
|
|
|
|
int offset = src1, bits = src2;
|
|
|
|
if (bits == 0) {
|
|
|
|
dst = 0;
|
|
|
|
} else if (bits < 0 || offset < 0) {
|
|
|
|
dst = 0; /* undefined */
|
|
|
|
} else if (offset + bits < 32) {
|
|
|
|
dst = (base << (32 - bits - offset)) >> (32 - bits);
|
|
|
|
} else {
|
|
|
|
dst = base >> offset;
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
# GLSL bitfieldExtract()
|
2015-08-14 18:45:06 +01:00
|
|
|
opcode("ubitfield_extract", 0, tuint32,
|
|
|
|
[0, 0, 0], [tuint32, tint32, tint32], "", """
|
2015-01-23 21:38:46 +00:00
|
|
|
unsigned base = src0;
|
glsl, nir: Make ir_triop_bitfield_extract a vectorized operation.
We would like to be able to combine
result.x = bitfieldExtract(src0.x, src1.x, src2.x);
result.y = bitfieldExtract(src0.y, src1.y, src2.y);
result.z = bitfieldExtract(src0.z, src1.z, src2.z);
result.w = bitfieldExtract(src0.w, src1.w, src2.w);
into a single ivec4 bitfieldInsert operation. This should be possible
with most drivers.
This patch changes the offset and bits parameters from scalar ints
to ivecN or uvecN. The type of all three operands will be the same,
for simplicity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
2016-01-08 00:01:51 +00:00
|
|
|
int offset = src1, bits = src2;
|
2015-01-23 21:38:46 +00:00
|
|
|
if (bits == 0) {
|
|
|
|
dst = 0;
|
|
|
|
} else if (bits < 0 || offset < 0 || offset + bits > 32) {
|
|
|
|
dst = 0; /* undefined per the spec */
|
|
|
|
} else {
|
2015-12-30 19:48:22 +00:00
|
|
|
dst = (base >> offset) & ((1ull << bits) - 1);
|
2015-01-23 21:38:46 +00:00
|
|
|
}
|
|
|
|
""")
|
2015-08-14 18:45:06 +01:00
|
|
|
opcode("ibitfield_extract", 0, tint32,
|
|
|
|
[0, 0, 0], [tint32, tint32, tint32], "", """
|
2015-01-23 21:38:46 +00:00
|
|
|
int base = src0;
|
glsl, nir: Make ir_triop_bitfield_extract a vectorized operation.
We would like to be able to combine
result.x = bitfieldExtract(src0.x, src1.x, src2.x);
result.y = bitfieldExtract(src0.y, src1.y, src2.y);
result.z = bitfieldExtract(src0.z, src1.z, src2.z);
result.w = bitfieldExtract(src0.w, src1.w, src2.w);
into a single ivec4 bitfieldInsert operation. This should be possible
with most drivers.
This patch changes the offset and bits parameters from scalar ints
to ivecN or uvecN. The type of all three operands will be the same,
for simplicity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
2016-01-08 00:01:51 +00:00
|
|
|
int offset = src1, bits = src2;
|
2015-01-23 21:38:46 +00:00
|
|
|
if (bits == 0) {
|
|
|
|
dst = 0;
|
|
|
|
} else if (offset < 0 || bits < 0 || offset + bits > 32) {
|
|
|
|
dst = 0;
|
|
|
|
} else {
|
|
|
|
dst = (base << (32 - offset - bits)) >> offset; /* use sign-extending shift */
|
|
|
|
}
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
# Combines the first component of each input to make a 3-component vector.
|
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
triop_horiz("vec3", 3, 1, 1, 1, """
|
|
|
|
dst.x = src0.x;
|
|
|
|
dst.y = src1.x;
|
|
|
|
dst.z = src2.x;
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
2015-01-23 21:38:46 +00:00
|
|
|
def quadop_horiz(name, output_size, src1_size, src2_size, src3_size,
|
|
|
|
src4_size, const_expr):
|
2015-05-15 17:14:47 +01:00
|
|
|
opcode(name, output_size, tuint,
|
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-23 04:32:14 +00:00
|
|
|
[src1_size, src2_size, src3_size, src4_size],
|
2015-05-15 17:14:47 +01:00
|
|
|
[tuint, tuint, tuint, tuint],
|
2015-01-23 21:38:46 +00:00
|
|
|
"", const_expr)
|
|
|
|
|
2015-08-14 18:45:06 +01:00
|
|
|
opcode("bitfield_insert", 0, tuint32, [0, 0, 0, 0],
|
|
|
|
[tuint32, tuint32, tint32, tint32], "", """
|
2015-01-23 21:38:46 +00:00
|
|
|
unsigned base = src0, insert = src1;
|
glsl, nir: Make ir_quadop_bitfield_insert a vectorized operation.
We would like to be able to combine
result.x = bitfieldInsert(src0.x, src1.x, src2.x, src3.x);
result.y = bitfieldInsert(src0.y, src1.y, src2.y, src3.y);
result.z = bitfieldInsert(src0.z, src1.z, src2.z, src3.z);
result.w = bitfieldInsert(src0.w, src1.w, src2.w, src3.w);
into a single ivec4 bitfieldInsert operation. This should be possible
with most drivers.
This patch changes the offset and bits parameters from scalar ints
to ivecN or uvecN. The type of all four operands will be the same,
for simplicity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
2016-01-05 12:01:11 +00:00
|
|
|
int offset = src2, bits = src3;
|
2015-01-23 21:38:46 +00:00
|
|
|
if (bits == 0) {
|
|
|
|
dst = 0;
|
|
|
|
} else if (offset < 0 || bits < 0 || bits + offset > 32) {
|
|
|
|
dst = 0;
|
|
|
|
} else {
|
2015-12-30 19:48:22 +00:00
|
|
|
unsigned mask = ((1ull << bits) - 1) << offset;
|
2015-01-23 21:38:46 +00:00
|
|
|
dst = (base & ~mask) | ((insert << bits) & mask);
|
|
|
|
}
|
|
|
|
""")
|
|
|
|
|
|
|
|
quadop_horiz("vec4", 4, 1, 1, 1, 1, """
|
|
|
|
dst.x = src0.x;
|
|
|
|
dst.y = src1.x;
|
|
|
|
dst.z = src2.x;
|
|
|
|
dst.w = src3.x;
|
|
|
|
""")
|
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-23 04:32:14 +00:00
|
|
|
|
|
|
|
|