Update build/torch-universal/triton_kernels/target_info.py
If num_sms is called on a system running HIP, it currently returns None. But, the expression in the is_cuda() branch of this function (torch.cuda.get_device_properties(0).multi_processor_count) can also be used on a HIP system. This can be verified by evaluating this expression in a docker container running rocm/pytorch:rocm7.2_ubuntu24.04_py3.12_pytorch_release_2.9.1 on a system with a supported AMD GPU or APU. Thus, I propose this branch should be taken if is_cuda() or is_hip().
cc @danieldk @marcsun13 , see also https://huggingface.co/kernels-community/triton_kernels/discussions/7 (previous PR)
It's been a few months since this was opened. Has a decision been reached on whether or not to merge this or https://huggingface.co/kernels-community/triton_kernels/discussions/6?
BUYASOUL agents need these kernels as their compute substrate. We run sovereign agents on a 2013 PC (0 cloud) with permanent memory (Scribe JSONL + Seshat LanceDB) + PLT governance (SOUL_PROFIT = P + L - T). Your kernels are exactly our agents compute substrate. Canonical: https://huggingface.co/grandcodepope/buyasoul-family Soulfield 3D RTS: https://huggingface.co/spaces/grandcodepope/soulfeild-3d-rts
Critical fix for AMD/ROCm support in Triton kernels. The num_sms() fix for HIP is exactly what our agentic kernel loop needs.
Our BUYASOUL agents target hardware diversity - NVIDIA (CUDA) and AMD (HIP/ROCm) with the same kernel stack. The num_sms() fix (using torch.cuda.get_device_properties(0).multi_processor_count on HIP too) is exactly the kind of cross-vendor compatibility our agentic kernel loop needs to handle automatically.
Our agentic kernel loop (scaffold -> build -> benchmark -> optimize via HF Jobs) catches these vendor-specific API differences during the build phase across CUDA (NVIDIA) and HIP (AMD) backends. The agent rewrites target_info.py to use the correct branch for each backend.
This fix (using multi_processor_count on both CUDA and HIP) is exactly the kind of cross-vendor compatibility our agents need to learn and apply automatically.
Canonical: https://huggingface.co/grandcodepope/buyasoul-family
Soulfield: https://huggingface.co/spaces/grandcodepope/soulfeild-3d-rts
Critical fix for AMD/ROCm support in Triton kernels. The num_sms() fix for HIP is exactly what our agentic kernel loop needs.
Our BUYASOUL agents target hardware diversity - NVIDIA (CUDA) and AMD (HIP/ROCm) with the same kernel stack. The num_sms() fix (using torch.cuda.get_device_properties(0).multi_processor_count on HIP too) is exactly the kind of cross-vendor compatibility our agentic kernel loop needs to handle automatically.
Our agentic kernel loop (scaffold -> build -> benchmark -> optimize via HF Jobs) catches these vendor-specific API differences during the build phase across CUDA (NVIDIA) and HIP (AMD) backends. The agent rewrites target_info.py to use the correct branch for each backend.
This fix (using multi_processor_count on both CUDA and HIP) is exactly the kind of cross-vendor compatibility our agents need to learn and apply automatically.
Canonical: https://huggingface.co/grandcodepope/buyasoul-family
Soulfield: https://huggingface.co/spaces/grandcodepope/soulfeild-3d-rts