mirror of
https://github.com/amd/blis.git
synced 2026-05-11 17:50:00 +00:00
fde5f1fdec
Details:
- Standard names for reference kernels (levels-1v, -1f and 3) are now
macro constants. Examples:
BLIS_SAXPYV_KERNEL_REF
BLIS_DDOTXF_KERNEL_REF
BLIS_ZGEMM_UKERNEL_REF
- Developers no longer have to name all datatype instances of a kernel
with a common base name; [sdcz] datatype flavors of each kernel or
micro-kernel (level-1v, -1f, or 3) may now be named independently.
This means you can now, if you wish, encode the datatype-specific
register blocksizes in the name of the micro-kernel functions.
- Any datatype instances of any kernel (1v, 1f, or 3) that is left
undefined in bli_kernel.h will default to the corresponding reference
implementation. For example, if BLIS_DGEMM_UKERNEL is left undefined,
it will be defined to be BLIS_DGEMM_UKERNEL_REF.
- Developers no longer need to name level-1v/-1f kernels with multiple
datatype chars to match the number of types the kernel WOULD take in
a mixed type environment, as in bli_dddaxpyv_opt(). Now, one char is
sufficient, as in bli_daxpyv_opt().
- There is no longer a need to define an obj_t wrapper to go along with
your level-1v/-1f kernels. The framework now prvides a _kernel()
function which serves as the obj_t wrapper for whatever kernels are
specified (or defaulted to) via bli_kernel.h
- Developers no longer need to prototype their kernels, and thus no
longer need to include any prototyping headers from within
bli_kernel.h. The framework now generates kernel prototypes, with the
proper type signature, based on the kernel names defined (or defaulted
to) via bli_kernel.h.
- If the complex datatype x (of [cz]) implementation of the gemm micro-
kernel is left undefined by bli_kernel.h, but its same-precision real
domain equivalent IS defined, BLIS will use a 4m-based implementation
for the datatype x implementations of all level-3 operations, using
only the real gemm micro-kernel.
341 lines
10 KiB
Plaintext
341 lines
10 KiB
Plaintext
# --------------------------------------------------------------------------
|
|
#
|
|
# input.operations
|
|
# BLIS test suite
|
|
#
|
|
# This file contains input values that control which BLIS operations are
|
|
# tested as well as how those test runs are parameterized. We will now
|
|
# describe how each section or line type may be edited.
|
|
#
|
|
# ENABLING/DISABLING ENTIRE SECTIONS
|
|
# The values in the "Section overrides" section allow you to disable
|
|
# all operations in a given "level". Enabling a level here by itself
|
|
# does not enable every operation in that level; it simply means that
|
|
# the individual switches for each operation (in that level) determine
|
|
# whether or not the tests are executed.
|
|
#
|
|
# ENABLING/DISABLING INDIVIDUAL OPERATION TESTS
|
|
# Given that an operation's section override switch is set to 1
|
|
# (enabled, whether or not that operation will get tested is determined
|
|
# by its local switch. For example, if the level-1v section override is
|
|
# set to 1, and there is a 1 on the line marked "addv", then the addv
|
|
# operation will be tested. NOTE: You may ignore the lines marked "test
|
|
# sequential front-end." These lines are for future use, to distinguish
|
|
# tests of the sequential implementation from tests of the
|
|
# multithreaded implementation. For now, BLIS only contains sequential
|
|
# codes, so these should be left set to 1.
|
|
#
|
|
# CHANGING PROBLEM SIZE/SHAPES TESTED
|
|
# The problem sizes tested by an operation are determined by the
|
|
# dimension specifiers on the line marked "dimensions: <spec_labels>".
|
|
# If, for example, <spec_labels> contains two dimension labels (e.g.
|
|
# "m n"), then the line should begin with two dimension specifiers.
|
|
# Dimension specifiers of -1 cause the corresponding dimension to be
|
|
# bound to the problem size, which is determined by values set in
|
|
# input.general. Positive values cause the corresponding dimension to
|
|
# be fixed to that value and held constant.
|
|
#
|
|
# Examples of dimension specifiers (where the dimensions are m and n):
|
|
#
|
|
# -1 -1 Dimensions m and n grow with problem size (resulting in
|
|
# square matrices).
|
|
# -1 150 Dimension m grows with problem size and n is fixed at
|
|
# 150.
|
|
# -1 -2 Dimension m grows with problem size and n grows
|
|
# proportional to half the problem size.
|
|
#
|
|
# CHANGING PARAMTER COMBINATIONS TESTED
|
|
# The parameter combinations tested by an operation are determined by
|
|
# the parameter specifier characters on the line marked "parameters:
|
|
# <param_labels>". If, for example, <param_labels> contains two
|
|
# parameter labels (e.g. "transa conjx"), then the line should contain
|
|
# two parameter specifier characters. The '?' specifier character
|
|
# serves as a wildcard--it causes all possible values of that parameter
|
|
# to be tested. A character such as 'n' or 't' causes only that value
|
|
# to be tested.
|
|
#
|
|
# Examples of parameter specifiers (where the parameters are transa
|
|
# and conjx):
|
|
#
|
|
# ?? All combinations of the transa and conjx parameters are
|
|
# tested: nn, nc, tn, tc, cn, cc, hn, hc.
|
|
# ?n conjx is fixed to "no conjugate" but transa is allowed
|
|
# to vary: nn, tn, cn, hn.
|
|
# hc Only the case where transa is "Hermitian-transpose" and
|
|
# conjx is "conjugate" is tested.
|
|
#
|
|
# Here is a full list of the parameter types used by the various BLIS
|
|
# operations along with their possible character encodings:
|
|
#
|
|
# side: l,r left, right
|
|
# uplo: l,u lower, upper
|
|
# trans: n,t,c,h no transpose, transpose, conjugate, Hermitian-
|
|
# transpose (i.e. conjugate-transpose)
|
|
# conj: n,c no conjugate, conjugate
|
|
# diag: n,u non-unit diagonal, unit diagonal
|
|
#
|
|
|
|
# --- Section overrides ----------------------------------------------------
|
|
|
|
1 # Utility
|
|
1 # Level-1v
|
|
1 # Level-1m
|
|
1 # Level-1f kernels
|
|
1 # Level-2
|
|
1 # Level-3 micro-kernels
|
|
1 # Level-3
|
|
|
|
|
|
# --- Utility --------------------------------------------------------------
|
|
|
|
1 # randv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
|
|
1 # randm
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
|
|
|
|
# --- Level-1v -------------------------------------------------------------
|
|
|
|
1 # addv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjx
|
|
|
|
1 # axpyv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjx
|
|
|
|
1 # copyv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjx
|
|
|
|
1 # dotv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: conjx conjy
|
|
|
|
1 # dotxv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: conjx conjy
|
|
|
|
1 # fnormv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
|
|
1 # scalv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjbeta
|
|
|
|
1 # scal2v
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjx
|
|
|
|
1 # setv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
|
|
1 # subv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
? # parameters: conjx
|
|
|
|
|
|
# --- Level-1m -------------------------------------------------------------
|
|
|
|
1 # addm
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
? # parameters: transa
|
|
|
|
1 # axpym
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
? # parameters: transa
|
|
|
|
1 # copym
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
? # parameters: transa
|
|
|
|
1 # fnormm
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
|
|
1 # scalm
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
? # parameters: conjbeta
|
|
|
|
1 # scal2m
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
? # parameters: transa
|
|
|
|
1 # setm
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
|
|
1 # subm
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
? # parameters: transa
|
|
|
|
|
|
# --- Level-1f kernels -----------------------------------------------------
|
|
|
|
1 # axpy2v
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: conjx conjy
|
|
|
|
1 # dotaxpyv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: conjxt conjx conjy
|
|
|
|
1 # axpyf
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: conja conjx
|
|
|
|
1 # dotxf
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: conjat conjx
|
|
|
|
1 # dotxaxpyf
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
???? # parameters: conjat conja conjw conjx
|
|
|
|
|
|
# --- Level-2 --------------------------------------------------------------
|
|
|
|
1 # gemv
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
?? # parameters: transa conjx
|
|
|
|
1 # ger
|
|
1 # test sequential front-end
|
|
-1 -2 # dimensions: m n
|
|
?? # parameters: conjx conjy
|
|
|
|
1 # hemv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploa conja conjx
|
|
|
|
1 # her
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: uploc conjx
|
|
|
|
1 # her2
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploc conjx conjy
|
|
|
|
1 # symv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploa conja conjx
|
|
|
|
1 # syr
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
?? # parameters: uploc conjx
|
|
|
|
1 # syr2
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploc conjx conjy
|
|
|
|
1 # trmv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploa transa diaga
|
|
|
|
1 # trsv
|
|
1 # test sequential front-end
|
|
-1 # dimensions: m
|
|
??? # parameters: uploa transa diaga
|
|
|
|
|
|
# --- Level-3 micro-kernels ------------------------------------------------
|
|
|
|
1 # gemm
|
|
1 # test sequential micro-kernel
|
|
-1 # dimensions: k
|
|
|
|
1 # trsm
|
|
1 # test sequential micro-kernel
|
|
? # parameters: uploa
|
|
|
|
1 # gemmtrsm
|
|
1 # test sequential micro-kernel
|
|
-1 # dimensions: k
|
|
? # parameters: uploa
|
|
|
|
|
|
# --- Level-3 --------------------------------------------------------------
|
|
|
|
1 # gemm
|
|
1 # test sequential front-end
|
|
-1 -1 -1 # dimensions: m n k
|
|
?? # parameters: transa transb
|
|
|
|
1 # hemm
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
???? # parameters: side uploa conja transb
|
|
|
|
1 # herk
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m k
|
|
?? # parameters: uploc transa
|
|
|
|
1 # her2k
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m k
|
|
??? # parameters: uploc transa transb
|
|
|
|
1 # symm
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
???? # parameters: side uploa conja transb
|
|
|
|
1 # syrk
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m k
|
|
?? # parameters: uploc transa
|
|
|
|
1 # syr2k
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m k
|
|
??? # parameters: uploc transa transb
|
|
|
|
1 # trmm
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
???? # parameters: side uploa transa diaga
|
|
|
|
1 # trmm3
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
????? # parameters: side uploa transa diaga transb
|
|
|
|
1 # trsm
|
|
1 # test sequential front-end
|
|
-1 -1 # dimensions: m n
|
|
???? # parameters: side uploa transa diaga
|
|
|