Triton 3.9.0 Removes Block Pointers, Drops Python 3.10 and Removes RDNA1/RDNA2 From the AMD Backend

Overview

The Triton GPU-kernel compiler published version 3.9.0 on October 27, 2026, according to the release page. The notes carry a Breaking Changes section that removes block pointers, drops Python 3.10 wheels and removes support for AMD’s RDNA1 and RDNA2 GPUs. The project’s release document says that starting with PyTorch 2.14, Triton feature releases “follow the PyTorch minor release cadence”.

What Changed

Language and runtime

Block pointers removed: per the release notes, tl.make_block_ptr raises NotImplementedError, tl.advance was removed, and tl.load/tl.store no longer accept boundary_check or padding_option. The notes tell users to switch to tensor descriptors (tl.make_tensor_descriptor or the host-side TensorDescriptor), which they say provide bounds checking and zero padding.
Keyword-only arguments: the same notes say cache_modifier and eviction_policy on tl.load/tl.store, volatile on tl.load, and keep_dims/ieee_rounding on tl.softmax are now keyword-only, so passing them positionally fails to compile.
Type promotion: the notes say a Python scalar no longer widens the result of tl.minimum, tl.maximum, comparisons, tl.clamp, tl.fma or binary math functions, so tl.maximum(x_fp16, 0.0) returns float16. They also say / and % return float32 when an operand is a float narrower than 32 bits.

Platforms and toolchain

Python 3.10 dropped: the release notes say Triton requires Python 3.11 or newer (>=3.11,<3.16) and no longer ships Python 3.10 wheels. The project’s release document lists the 3.8.0 wheels as supporting >=3.10, <=3.14.
RDNA1/RDNA2 removed: the notes say the AMD backend no longer supports gfx10 targets (gfx101x, gfx103x) and tell users of those GPUs to use Triton 3.8.
Hopper compiler selection: sm_90 now compiles with the CUDA 13 ptxas, whose path is set with TRITON_PTXAS_BLACKWELL_PATH; TRITON_PTXAS_PATH applies only below sm_90, according to the notes.
Build changes: the Python bindings moved from pybind11 to nanobind, so PYBIND11_SYSPATH is no longer used. AMD code generation now uses its own LLVM pin, and the notes say a custom build should set TRITON_AMD_CODEGEN_PATH to a prebuilt libtriton_amd_codegen library.

Other additions

The release notes list new tl.atomic_load and tl.atomic_store operations (loads default to acquire, stores to release), tl.fdiv(..., approx=True) for fast FP32 division, and support for chained comparisons such as 0 <= x <= 8 inside kernels. They also say E8M0 scale decoding changed so that 0x00 now decodes to 2^-127 and 0xFF to NaN, previously zero and infinity, which “changes results for kernels that use those values”. The notes describe a rewrite of barrier insertion as a standalone pass, and fixes for wrong results in nested-loop flattening, reductions and scans.

Deprecations Ahead of 3.10

The notes say Triton 3.10 will turn off implicit floating-point fusion (multiply-add to FMA) by default. In 3.9, fusion stays on, and Triton warns once per process when it compiles a kernel that does not set enable_fp_fusion. Setting TRITON_DEFAULT_FP_FUSION=0 adopts the 3.10 default now, while =1 keeps fusion and silences the warning. The notes also say can_reorder=True on tl.cat, tl.reshape and tl.ravel still works in 3.9 but warns, and that 3.10 will remove it.

What We Don’t Know

The release notes are the main account of the changes cited here, and they do not say how many existing kernels or downstream projects use block pointers. No independent migration reports were reviewed. The Herald has previously reported on a TRL release that turned on a Triton fused LM head by default; whether it or other libraries need changes for 3.9.0 is not addressed in the notes.