leavelet/cutlass
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Updates for 3.1 (#932)

Browse Source
This commit is contained in:
ANIKET SHIVAM
2023-04-29 06:34:27 -07:00
committed by GitHub
parent 6f8596ce3f
commit 7c04f95415
51 changed files with 1796 additions and 328 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
examples/08_turing_tensorop_gemm/CMakeLists.txt
View File

@@ -31,5 +31,6 @@
cutlass_example_add_executable(
08_turing_tensorop_gemm
turing_tensorop_gemm.cu
DISABLE_TESTS ON
)

1
examples/12_gemm_bias_relu/CMakeLists.txt
View File

@@ -31,5 +31,6 @@
cutlass_example_add_executable(
12_gemm_bias_relu
gemm_bias_relu.cu
DISABLE_TESTS ON
)

2
examples/31_basic_syrk/basic_syrk.cu
View File

@@ -34,7 +34,7 @@
matrix multiply kernel to verify its correctness.
The CUTLASS Syrk template is instantiated in the function CutlassSsyrkNN. This is kernel computes
the symmetric rank-k update (SYRK) using double-precision doubleing-point arithmetic and assumes
the symmetric rank-k update (SYRK) using double-precision floating-point arithmetic and assumes
all matrices have column-major layout.
The threadblock tile size is chosen as 16x32x16 which offers good performance for large matrices.

2
examples/32_basic_trmm/basic_trmm.cu
View File

@@ -34,7 +34,7 @@
matrix multiply kernel to verify its correctness.
The CUTLASS Trmm template is instantiated in the function CutlassStrmmNN. This is kernel computes
the triangular matrix product (TRMM) using double-precision doubleing-point arithmetic and assumes
the triangular matrix product (TRMM) using double-precision floating-point arithmetic and assumes
all matrices have column-major layout.
The threadblock tile size is chosen as 64x64x16 which offers good performance for large matrices.

6
examples/47_ampere_gemm_universal_streamk/ampere_gemm_universal_streamk.cu
View File

@@ -495,7 +495,7 @@ int main(int argc, const char **argv)
options.tensor_d.resize(options.problem_size.mn()); // <- Create matrix D with dimensions M x N used to store output from CUTLASS kernel
options.tensor_ref_d.resize(options.problem_size.mn()); // <- Create matrix D with dimensions M x N used to store output from reference kernel
// Fill matrix A on host with uniform-random data [4, -4]
// Fill matrix A on host with uniform-random data [2, -2]
cutlass::reference::host::TensorFillRandomUniform(
options.tensor_a.host_view(),
1,
@@ -503,7 +503,7 @@ int main(int argc, const char **argv)
ElementA(-2),
0);
// Fill matrix B on host with uniform-random data [4, -4]
// Fill matrix B on host with uniform-random data [2, -2]
cutlass::reference::host::TensorFillRandomUniform(
options.tensor_b.host_view(),
1,
@@ -511,7 +511,7 @@ int main(int argc, const char **argv)
ElementB(-2),
0);
// Fill matrix C on host with uniform-random data [4, -4]
// Fill matrix C on host with uniform-random data [2, -2]
cutlass::reference::host::TensorFillRandomUniform(
options.tensor_c.host_view(),
1,

10
examples/49_hopper_gemm_with_collective_builder/49_collective_builder.cu
View File

@@ -84,9 +84,10 @@
therefore letting the builder pick the collective specialization.
CUTLASS builders make an attempt to pick the best schedule when `Auto` is provided such that the
assembled collctives have the best performance, but this is not a guarantee. A user relying on `Auto`
assembled collectives have the best performance, but this is not a guarantee. A user relying on `Auto`
may get a free performance upgrade with newer CUTLASS releases in case we can provide more optimized
implementations that the builder can transparently assemble for `Auto`.
implementations that the builder can transparently assemble for `Auto`. But a user should not rely on
`Auto` if they require a specific scheduling policy and/or stage count to be used.
If a user decides to let the builders pick the collective specialization via `Auto` schedules,
they must be used for both mainloop and epilogue alike to ensure compatibility between the
@@ -99,11 +100,6 @@
in this manner remains the primary API for using CUTLASS 3 kernels. `CollectiveBuilder`s are
simply meant to be a convenience interface.
Note also that, while the selections made by CollectiveBuilder attempt to maximize performance, this is not
a guarantee. Furthermore, the behavior of the CollectiveBuilder when `Auto` parameters are provided is subject
to change in future CUTLASS releases -- do not rely on `Auto` if you require a specific scheduling policy and/or
stage count to be used.
Details of this example
-----------------------
This example walks through the use of the CollectiveBuilder with various schedules and stage counts specified.