From 08f239e5c309747bad89905e26f2d5beb917c095 Mon Sep 17 00:00:00 2001 From: Krishna Kalyan Date: Wed, 19 Aug 2026 00:41:14 +0530 Subject: [PATCH] docs: mention CuteDSL as CUDA max-autotune backend --- unstable_source/max_autotune_on_CPU_tutorial.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unstable_source/max_autotune_on_CPU_tutorial.rst b/unstable_source/max_autotune_on_CPU_tutorial.rst index 47374744938..c8c0c15d71d 100644 --- a/unstable_source/max_autotune_on_CPU_tutorial.rst +++ b/unstable_source/max_autotune_on_CPU_tutorial.rst @@ -19,7 +19,10 @@ The ``max-autotune`` mode for the Inductor CPU backend in ``torch.compile`` (`RF profiles multiple implementations of operations at compile time and selects the best-performing one, trading longer compilation times for improved runtime performance. This enhancement is particularly beneficial for GEMM-related operations. In the Inductor CPU backend, we’ve introduced a C++ template-based GEMM implementation as an alternative to the ATen-based approach that relies on oneDNN and MKL libraries. -This is similar to the max-autotune mode on CUDA, where implementations from ATen, Triton, and CUTLASS are considered. +This is similar to the max-autotune mode on CUDA, where implementations from ATen, Triton, CUTLASS, and CuteDSL are considered. +The CuteDSL backend (``NVGEMM``) is opt-in and requires additional packages; see +`Generating State-of-the-Art GEMMs with TorchInductor's CuteDSL backend `_ +for setup instructions and benchmark results. We have covered most popular data types, including FP32, BF16, FP16, and INT8, with epilogue fusions for x86 CPUs.