Repository navigation
Conversation
|
👋 Hi! Thank you for contributing to the TileLang project. Please remember to run We appreciate you taking this step! Our team will review your contribution, and we look forward to your awesome work! 🚀 |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds CUDA device helpers ChangesPrecision Conversion Helpers
CutDSL handle_add_byte_offset
Metal module creation
Sequence Diagram(s)sequenceDiagram
participant Caller
participant memcpy_storage
participant __nv_cvt_fp8x2_to_halfraw2
Caller->>memcpy_storage: memcpy input into __nv_fp8x2_storage_t
memcpy_storage->>__nv_cvt_fp8x2_to_halfraw2: call with __NV_E4M3
__nv_cvt_fp8x2_to_halfraw2->>memcpy_storage: return __half2
memcpy_storage->>Caller: return as T via reinterpret_cast
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
0cf1746 to
3a05620
Compare
Generated CUDA for per-token cast benchmarks can reduce pre-quantized
FP8/FP4 values through half2 absmax operations. The generated loads cast
packed fp8_e4_2_t/fp4_e2_2_t storage with from_uint1<__half2>, but
common.h only exposes from_uint1 for uint1 storage, so NVCC rejects
overload resolution for the packed FP8/FP4 arguments.
This is needed for TileKernels workloads that exercise the packed FP8/FP4
per-token cast path to compile and run on the H100 CUDA backend.
Previous compile errors looked like:
<build-temp>/tvm_kernels.cu(45): error: no instance of function template "tl::from_uint1" matches the argument list
argument types are: (fp8_e4_2_t)
stage1_amax_fragment_pack[i_1] = tl::to_uint1(tl::max2(tl::from_uint1<__half2>(stage1_amax_fragment_pack[i_1]), tl::from_uint1<__half2>(tl::to_uint1(tl::abs2(tl::from_uint1<__half2>(*(fp8_e4_2_t*)(x_stage1_fragment_reshaped + ((i_1 * 16) + (rv * 2)))))))));
^
<tilelang>/src/tl_templates/cuda/common.h(696): note tile-ai#3326-D: function template "tl::from_uint1" does not match because argument tile-ai#1 does not match parameter
template <typename T> TL_DEVICE T from_uint1(uint1 v) {
and:
<build-temp>/tvm_kernels.cu(46): error: no instance of function template "tl::from_uint1" matches the argument list
argument types are: (fp4_e2_2_t)
stage1_amax_fragment_pack[i_1] = tl::to_uint1(tl::max2(tl::from_uint1<__half2>(stage1_amax_fragment_pack[i_1]), tl::from_uint1<__half2>(tl::to_uint1(tl::abs2(tl::from_uint1<__half2>(*(fp4_e2_2_t*)(x_stage1_fragment_reshaped_packed + ((i_1 * 8) + rv))))))));
^
<tilelang>/src/tl_templates/cuda/common.h(696): note tile-ai#3326-D: function template "tl::from_uint1" does not match because argument tile-ai#1 does not match parameter
template <typename T> TL_DEVICE T from_uint1(uint1 v) {
Add dtype-local conversion overloads in the CUDA FP8 and FP4 template
headers. The FP8 bridge converts fp8_e4_2_t through
__nv_fp8x2_storage_t and __nv_cvt_fp8x2_to_halfraw2(..., __NV_E4M3),
while the FP4 bridge converts fp4_e2_2_t through the existing
__tl_cvt_fp4x2_to_half2 helper. Keeping these bridges next to the
packed dtype definitions avoids making common.h depend on dtype-specific
packed storage.
Verified on H100 (sm_90, 114 SMs) with CUDA 13.2 and PyTorch
2.12.0+cu132:
* representative packed/TMA FP8 and FP4 per_token_cast benchmark cases:
2 passed
* full per_token_cast benchmark: 448 passed
* representative functional validation for engram_grad_w_reduce and
packed/TMA per_token_cast cases: 8 passed
The original NVCC errors for tl::from_uint1 with fp8_e4_2_t and
fp4_e2_2_t arguments no longer appear.
SHA256: jI7EV9upQPdrme7/WRvrms9GDUfQR/FMJfEDNpdbWxc
3a05620 to
62751f7
Compare
Make the CuTeDSL Python codegen handle tirx.handle_add_byte_offset instead of falling back to CodeGenTileLangPY and failing with an unresolved call. The helper preserves byte-offset semantics by recasting tensor or pointer handles to Uint8 before applying the offset. This is needed for dynamic shared-memory aliases generated by TileLang lowering, such as the CuTeDSL GEMM JIT path. Verified with nvidia-cutlass-dsl-libs-base 4.5.0 on CUDA: * testing/python/jit/test_tilelang_jit_cutedsl.py::test_gemm_jit_kernel * testing/python/jit/test_tilelang_jit_cutedsl.py::test_cutedsl_kernel_multi_stream * testing/python/jit/test_tilelang_jit_cutedsl.py::test_cutedsl_dynamic_shape * testing/python/jit/test_tilelang_jit_cutedsl.py
4edd8d8 to
246e9c2
Compare
TileLang always builds Metal codegen so Metal shader source can be generated on non-macOS hosts, but its module creation wrapper still required a registered Metal module factory. On Linux CI this made source-only Metal codegen tests fail with "Metal module factory not available." Reuse TVM’s MetalModuleCreateWithFallback so real Metal runtime builds still use ffi.Module.create.metal, while builds without Metal runtime get the source-inspectable fallback module. Verified: * testing/python/metal/test_metal_codegen_linux.py::test_metal_codegen_float16 * testing/python/metal/test_metal_codegen_linux.py::test_metal_codegen_int32 * testing/python/metal/test_metal_gemm_v2_linux.py::test_metal_gemm_v2_float16 * testing/python/metal/test_metal_codegen_linux.py::test_metal_codegen_float32 * testing/python/metal
012a89e to
d1b4065
Compare
CuTeDSL examples that allocate T.tfloat32 buffers originally failed because custom[tfloat32] had no dtype mapping in DTypeToString. Mapping it directly to cutlass.TFloat32 allowed codegen to proceed, but ordinary elementwise expressions such as x_frag * x_frag then produced invalid MLIR arith.muli operations on tf32 values. Represent custom[tfloat32] as cutlass.Float32 for CuTeDSL storage, recasts, and elementwise arithmetic. TileLang tfloat32 has the same memory layout as float32, and CuTeDSL MMA helpers still select TF32 instructions through the PTX/WGMMA dtype strings, so the tensor-core path keeps TF32 semantics without using the TF32 scalar type for general arithmetic.
The grouped_gemm example test calls the backward runner with the same tuning keyword arguments as the forward runners, including block_N, block_K, num_stages, threads, trans_b, and profile. The backward runner only accepted block_M and hard-coded the remaining launch parameters, which raised:\n\n TypeError: run_tilelang_grouped_gemm() got an unexpected keyword argument 'block_N'\n\nAccept the same public runner arguments, pass the tuning values through the autograd wrapper into forward and backward kernels, and return None gradients for the non-tensor autograd arguments. Keep transposed B unsupported explicitly for this backward example.
d1b4065 to
30a200d
Compare
Generated CUDA for per-token cast benchmarks can reduce pre-quantized FP8/FP4 values through half2 absmax operations. The generated loads cast packed fp8_e4_2_t/fp4_e2_2_t storage with from_uint1<__half2>, but common.h only exposes from_uint1 for uint1 storage, so NVCC rejects overload resolution for the packed FP8/FP4 arguments.
This is needed for TileKernels workloads that exercise the packed FP8/FP4 per-token cast path to compile and run on the H100 CUDA backend.
Previous compile errors looked like:
and:
Add dtype-local conversion overloads in the CUDA FP8 and FP4 template headers. The FP8 bridge converts fp8_e4_2_t through __nv_fp8x2_storage_t and __nv_cvt_fp8x2_to_halfraw2(..., __NV_E4M3), while the FP4 bridge converts fp4_e2_2_t through the existing __tl_cvt_fp4x2_to_half2 helper. Keeping these bridges next to the packed dtype definitions avoids making common.h depend on dtype-specific packed storage.
Verified on H100 (sm_90, 114 SMs) with CUDA 13.2 and PyTorch 2.12.0+cu132:
The original NVCC errors for tl::from_uint1 with fp8_e4_2_t and fp4_e2_2_t arguments no longer appear.
Summary by CodeRabbit