Repository navigation
Expose CUDA function properties for Warp kernels #1805
Description
Description
CUDA exposes properties of a compiled function through cuFuncGetAttribute(). Two of those properties are especially useful when inspecting generated kernel code:
CU_FUNC_ATTRIBUTE_NUM_REGS: registers used by each threadCU_FUNC_ATTRIBUTE_LOCAL_SIZE_BYTES: local-memory bytes used by each thread
These are also available as numRegs and localSizeBytes in the CUDA Runtime API's cudaFuncAttributes structure.
Add public Warp functions for querying these properties:
wp.get_cuda_kernel_register_count(kernel, device=None, block_dim=None) -> intwp.get_cuda_kernel_local_memory_size(kernel, device=None, block_dim=None) -> int
Both functions should query the forward CUDA function for the module variant selected by device and block_dim. Warp should compile and load the variant lazily if needed.
The queries should return the values reported by CUDA without launching the kernel or changing its launch attributes. The local-memory result includes compiler-generated spills and other thread-local storage, so it is not a spill-only metric.
Context
CUDA function properties depend on the compiled function and the device where it is loaded. They can change with the CUDA toolchain, compilation options, target architecture, Warp version, or block_dim.
Warp currently has no public way to read these properties. Exposing them would let users compare compiled kernel variants without relying on external CUDA tools or Warp internals.
The APIs would also provide useful measurements for the register-tuning options proposed in #1671.
Activity
Expose CUDA kernel resource queries (NVIDIAGH-1805)
Expose CUDA kernel resource queries (NVIDIAGH-1805)
Expose CUDA kernel resource queries (NVIDIAGH-1805)
Expose CUDA kernel resource queries (NVIDIAGH-1805)
Expose CUDA kernel properties (NVIDIAGH-1805)
Expose CUDA kernel resource queries [NVIDIAGH-1805]
shi-eric commentedon Aug 19, 2026
This is addressed by 7336503.
The implementation consolidates the two proposed scalar queries into
wp.get_cuda_kernel_properties(), which returnsregister_countandlocal_memory_sizein one extensible dictionary. It queries the compiled forward CUDA entry point for the requested device and block-dimension variant, compiling and loading that variant lazily when necessary, without launching the kernel or applying launch configuration.Public API behavior
wp.get_cuda_kernel_properties(kernel, device=None, block_dim=None)returns the CUDA-reported register count and local-memory bytes per thread.wp.overload()are supported. Generic parent kernels, CPU devices, invalid kernels, and invalid block dimensions produce contextual errors.Test coverage
warp/tests/cuda/test_kernel_attributes.py:TestKernelAttributescovers the returned property dictionary, the batched native query, block-dimension variant selection, module defaults, lazy compilation, and supported kernel forms.warp/tests/cuda/test_occupancy.py:test_suggested_block_size_rejects_generic_parentcovers the new generic-kernel error, whiletest_suggested_block_size_cpuconfirms that generic kernels retain the existing CPU fallback.Behavioral verification
An issue-shaped CUDA probe queried an unlaunched kernel at
block_dim=64andblock_dim=128. Both variants returned valid properties and were loaded independently without executing the kernel or configuring shared-memory or cluster attributes. A subsequent explicit launch produced the expected output.Follow-up to consider
device=Noneto cover the documented default-device path explicitly. This does not block closure because the implementation delegates to Warp's standard default-device resolver.Expose CUDA kernel resource queries [NVIDIAGH-1805]