<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>hgpu.org</title>
	<atom:link href="https://hgpu.org/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>https://hgpu.org</link>
	<description>High performance computing on Graphics Processing Units</description>
	<lastBuildDate>Sun, 10 May 2026 21:42:15 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
<site xmlns="com-wordpress:feed-additions:1">56702024</site>	<item>
		<title>DITRON: Distributed Multi-level Tiling Compiler for Parallel Tensor Programs</title>
		<link>https://hgpu.org/?p=30797</link>
					<comments>https://hgpu.org/?p=30797#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 10 May 2026 21:42:15 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia H800]]></category>
		<category><![CDATA[Package]]></category>
		<category><![CDATA[Triton]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30797</guid>

					<description><![CDATA[The scaling of large language models (LLMs) is currently bottlenecked by the rigidity of distributed programming. While high-performance libraries like CuBLAS and NCCL provide optimized primitives, they lack the flexibility required for rapidly evolving model architectures. Conversely, existing tensor compilers fail to address the complex memory hierarchy of distributed clusters effectively. To bridge this gap, [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>The scaling of large language models (LLMs) is currently bottlenecked by the rigidity of distributed programming. While high-performance libraries like CuBLAS and NCCL provide optimized primitives, they lack the flexibility required for rapidly evolving model architectures. Conversely, existing tensor compilers fail to address the complex memory hierarchy of distributed clusters effectively. To bridge this gap, we propose DITRON, a scalable tile-level compiler that democratizes high-performance distributed kernel development. DITRON introduces a novel hierarchical programming abstraction spanning Core, Device, and Task levels to map tensor programs efficiently onto heterogeneous distributed hardware. This abstraction allows DITRON to support diverse parallelism strategies while abstracting away the complexity of inter-node and intra-node communication. Evaluated across large-scale clusters, DITRON achieves performance parity with or exceeding expert-tuned CUDA libraries, delivering speedups of  on isolated kernels and  on end-to-end inference in vLLM. Furthermore, DITRON demonstrates strong portability, achieving significant speedups on both NVIDIA and AMD platforms. ours{} has been deployed at the enterprise level for both training and inference. It achieves an MFU improvement of over 10% in training tasks, saving approximately 500,000 GPU hours of training cost per month. For inference tasks, it delivers an end-to-end gain of over 20% and has been applied to cloud service inference and edge inference scenarios.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30797</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30797</post-id>	</item>
		<item>
		<title>Microbenchmark-Driven Analytical Performance Modeling Across Modern GPU Architectures</title>
		<link>https://hgpu.org/?p=30796</link>
					<comments>https://hgpu.org/?p=30796#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 10 May 2026 21:42:15 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[AMD]]></category>
		<category><![CDATA[AMD Radeon Instinct MI250X]]></category>
		<category><![CDATA[AMD Radeon Instinct MI300A]]></category>
		<category><![CDATA[Benchmarking]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia B200]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30796</guid>

					<description><![CDATA[Rapidly evolving GPU architectures featuring complex memory hierarchies, matrix units, and varied precision formats continue to widen the gap between theoretical peaks and achievable performance. We design and develop analytical performance models for NVIDIA Blackwell (B200) and AMD CDNA3 (MI300A) grounded in systematic microbenchmark characterization. For Blackwell, the model captures Tensor Memory (TMEM), asynchronous bulk [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Rapidly evolving GPU architectures featuring complex memory hierarchies, matrix units, and varied precision formats continue to widen the gap between theoretical peaks and achievable performance. We design and develop analytical performance models for NVIDIA Blackwell (B200) and AMD CDNA3 (MI300A) grounded in systematic microbenchmark characterization. For Blackwell, the model captures Tensor Memory (TMEM), asynchronous bulk copy (TMA), and 5th-generation tensor cores; for CDNA3, the model captures Infinity Cache hierarchy, VGPR constraints, and occupancy. Validation yields 1.31% MAE on B200 (21 kernels) and 0.09% on MI300A (27 kernels), while naive roofline baselines exceed 95% error on the same kernels. We further validate the models using Rodinia 3.1 and SPEChpc 2021 this http URL models are updated with HBM bandwidth, capacity, and cache parameters and applied to H200 (Hopper) and MI250X (CDNA2), indicating no major restructuring of the models are needed. All models and benchmarks will be released as open-source upon acceptance.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30796</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30796</post-id>	</item>
		<item>
		<title>CuBridge: An LLM-Based Framework for Understanding and Reconstructing High-Performance Attention Kernels</title>
		<link>https://hgpu.org/?p=30795</link>
					<comments>https://hgpu.org/?p=30795#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 10 May 2026 21:42:15 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[Deep learning]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia A100]]></category>
		<category><![CDATA[nVidia H100]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30795</guid>

					<description><![CDATA[Efficient CUDA implementations of attention mechanisms are critical to modern deep learning systems, yet supporting diverse and evolving attention variants remains challenging. Existing frameworks and compilers trade performance for flexibility, while expert-written kernels achieve high efficiency but are difficult to adapt. Recent work explores large language models (LLMs) for GPU kernel generation, but prior studies [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Efficient CUDA implementations of attention mechanisms are critical to modern deep learning systems, yet supporting diverse and evolving attention variants remains challenging. Existing frameworks and compilers trade performance for flexibility, while expert-written kernels achieve high efficiency but are difficult to adapt. Recent work explores large language models (LLMs) for GPU kernel generation, but prior studies report unstable correctness and significant performance gaps for complex operators such as attention. We present CuBridge, an LLM-based framework that adapts expert-written attention kernels through a structured lift-transfer-lower workflow. CuBridge starts from expert-written CUDA attention kernels and lifts them into an executable intermediate representation that makes execution orchestration explicit while abstracting low-level CUDA syntax. Given a user-provided PyTorch specification, CuBridge generates and verifies a target IR program, then reconstructs optimized CUDA code via reference-guided lowering. Across diverse attention variants and GPU platforms, CuBridge consistently produces correct kernels and substantially outperforms general frameworks, compiler-based approaches, and prior LLM-based methods.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30795</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30795</post-id>	</item>
		<item>
		<title>KEET: Explaining Performance of GPU Kernels Using LLM Agents</title>
		<link>https://hgpu.org/?p=30794</link>
					<comments>https://hgpu.org/?p=30794#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 10 May 2026 21:42:15 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia H100]]></category>
		<category><![CDATA[Performance]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30794</guid>

					<description><![CDATA[Performance profiles of GPU kernels generated by tools such as Nsight Compute are rich in detail but are often challenging to interpret. To achieve the best performance possible on a given GPU architecture, kernel developers need to spend significant time analyzing and comparing profiles in the tool&#8217;s graphical interface to identify and understand kernel performance [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Performance profiles of GPU kernels generated by tools such as Nsight Compute are rich in detail but are often challenging to interpret. To achieve the best performance possible on a given GPU architecture, kernel developers need to spend significant time analyzing and comparing profiles in the tool&#8217;s graphical interface to identify and understand kernel performance bottlenecks. Large Language Models (LLMs) have shown promise in understanding complex data and generating natural language explanations. In this paper, we propose the Kernel Execution Explanation Toolkit (KEET), an LLM-based agentic framework for interpreting Nsight Compute profiles to generate useful and data-grounded natural language explanations of performance issues in GPU kernels, and suggestions for optimizations. We evaluate KEET using several CUDA kernels of varying complexity on NVIDIA H100 GPUs. We find that the generated explanations, when provided as context, improve the quality of LLM code optimization and multiple-choice question answering in downstream tasks. We further demonstrate that the tool can be used to interpret performance data from large sets of profiles to improve the quality of optimization suggestions.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30794</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30794</post-id>	</item>
		<item>
		<title>Kerncap: Automated Kernel Extraction and Isolation for AMD GPUs</title>
		<link>https://hgpu.org/?p=30793</link>
					<comments>https://hgpu.org/?p=30793#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 10 May 2026 21:42:15 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[AMD]]></category>
		<category><![CDATA[AMD Radeon Instinct MI210]]></category>
		<category><![CDATA[AMD Radeon Instinct MI300X]]></category>
		<category><![CDATA[AMD Radeon Pro W7900]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[Package]]></category>
		<category><![CDATA[Python]]></category>
		<category><![CDATA[ROCm]]></category>
		<category><![CDATA[Triton]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30793</guid>

					<description><![CDATA[Iterative GPU kernel tuning is bottlenecked by the scale of the applications that host the kernels. Rapid iteration requires isolating the kernel so it can be edited, recompiled, and validated without rebuilding the full application &#8212; but manual isolation requires reconstructing build flags, dispatch configuration, and runtime inputs by hand, so developers usually settle for [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Iterative GPU kernel tuning is bottlenecked by the scale of the applications that host the kernels. Rapid iteration requires isolating the kernel so it can be edited, recompiled, and validated without rebuilding the full application &#8212; but manual isolation requires reconstructing build flags, dispatch configuration, and runtime inputs by hand, so developers usually settle for slow in-place edits. We present Kerncap, an automated kernel extraction tool that intercepts dispatches at the HSA runtime for both HIP and Triton, bridging Triton&#8217;s JIT-only metadata into HSA-level capture via a lightweight Python compile-hook shim. Kerncap performs an address-space closure of all device memory &#8212; a virtual-address-faithful snapshot that preserves embedded device pointers without DWARF metadata or pointer chasing &#8212; locates kernel sources, and emits self-contained reproducer projects. HIP reproducers use a Clang VFS overlay for source-level recompilation without modifying the original build system; Triton reproducers are tuning-pinned, binding the captured autotuner configuration into the artifact to preserve the JIT kernel&#8217;s numerical contract.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30793</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30793</post-id>	</item>
		<item>
		<title>ARGUS: Agentic GPU Optimization Guided by Data-Flow Invariants</title>
		<link>https://hgpu.org/?p=30764</link>
					<comments>https://hgpu.org/?p=30764#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 03 May 2026 20:48:31 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[AMD]]></category>
		<category><![CDATA[AMD Radeon Instinct MI300X]]></category>
		<category><![CDATA[DSL]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[Triton]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30764</guid>

					<description><![CDATA[LLM-based coding agents can generate functionally correct GPU kernels, yet their performance remains far below hand-optimized libraries on critical computations such as matrix multiplication, attention, and Mixture-of-Experts (MoE). Peak GPU performance requires coordinated reasoning over tightly coupled optimizations, including tiling, shared-memory staging, software pipelining, and instruction scheduling, while existing agents rely on sparse pass/fail feedback, [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>LLM-based coding agents can generate functionally correct GPU kernels, yet their performance remains far below hand-optimized libraries on critical computations such as matrix multiplication, attention, and Mixture-of-Experts (MoE). Peak GPU performance requires coordinated reasoning over tightly coupled optimizations, including tiling, shared-memory staging, software pipelining, and instruction scheduling, while existing agents rely on sparse pass/fail feedback, leaving them unable to diagnose global constraint violations. We present Argus, an agentic framework that addresses this through data-flow invariants: compile-time specifications encoding how data must be choreographed throughout kernel execution. Argus introduces a tile-based, Pythonic DSL exposing hardware instructions and compiler policies while hiding low-level representations. The DSL provides tag functions to propagate symbolic annotations through data and control flow, and tag assertions to enforce relational constraints at use sites. When violations occur, the compiler returns concrete counterexamples identifying the thread, data element, and program point, enabling dense, structured feedback for targeted fixes. Invariants are verified at compile time via abstract interpretation over a layout algebra and SMT solving, with zero runtime overhead. An in-context reinforcement learning planner learns to select optimizations and synthesize effective invariants, supported by a curated knowledge base of GPU optimization techniques. We evaluate Argus on the AMD MI300X GPU across GEMM, flash attention, and MoE kernels accounting for over 90% of GPU time in LLM inference. Generated kernels achieve 99-104% of state-of-the-art hand-optimized assembly throughput and are 2-1543x faster than existing agentic systems. Argus further generalizes to 200 KernelBench tasks, solving 100% of Level 1 and 90% of Level 2 problems.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30764</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30764</post-id>	</item>
		<item>
		<title>Evaluating CUDA Tile for AI Workloads on Hopper and Blackwell GPUs</title>
		<link>https://hgpu.org/?p=30763</link>
					<comments>https://hgpu.org/?p=30763#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 03 May 2026 20:37:19 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[CUBLAS]]></category>
		<category><![CDATA[LLM]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia B200]]></category>
		<category><![CDATA[nVidia H100]]></category>
		<category><![CDATA[nVidia RTX PRO 6000]]></category>
		<category><![CDATA[Package]]></category>
		<category><![CDATA[Performance]]></category>
		<category><![CDATA[Triton]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30763</guid>

					<description><![CDATA[NVIDIA&#8217;s CUDA Tile (CuTile) introduces a Python-based, tile-centric abstraction for GPU kernel development that aims to simplify programming while retaining Tensor Core and Tensor Memory Accelerator (TMA) efficiency on modern GPUs. We present the first independent, cross-architecture evaluation of CuTile against established approaches such as cuBLAS, Triton, WMMA, and raw SIMT on three NVIDIA GPUs [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>NVIDIA&#8217;s CUDA Tile (CuTile) introduces a Python-based, tile-centric abstraction for GPU kernel development that aims to simplify programming while retaining Tensor Core and Tensor Memory Accelerator (TMA) efficiency on modern GPUs. We present the first independent, cross-architecture evaluation of CuTile against established approaches such as cuBLAS, Triton, WMMA, and raw SIMT on three NVIDIA GPUs spanning Hopper and Blackwell: H100 NVL, B200, and RTX PRO 6000 Blackwell Server Edition. We benchmark representative AI workloads, including GEMM, fused multi-head attention, and end-to-end LLM inference in BF16/FP16 precision, to assess both performance and portability. Our results show that CuTile effectiveness is strongly workload- and architecture-dependent. On datacenter-class Blackwell (B200), CuTile achieves up to 1007 TFLOP/s for fused attention, outperforming FlashAttention-2 by 2.5x while requiring only 60 lines of Python kernel code. For GEMM, CuTile reaches 52-79% of cuBLAS performance in 22 lines of code (versus 123 for WMMA), making it a practical replacement for hand-written CUDA kernels but not yet for vendor-optimized libraries. However, the same CuTile attention kernel achieves only 53% of FlashAttention-2 throughput on RTX PRO 6000 (sm_120), exposing significant cross-architecture optimization gaps. In contrast, Triton sustains 62-101% of cuBLAS performance across all tested platforms without architecture-specific tuning, demonstrating substantially stronger portability.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30763</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30763</post-id>	</item>
		<item>
		<title>A Human–Machine Collaborative Tuning Framework for Triton Kernel Optimization on SIMD Platforms</title>
		<link>https://hgpu.org/?p=30762</link>
					<comments>https://hgpu.org/?p=30762#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 03 May 2026 20:37:19 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[Auto-Tuning]]></category>
		<category><![CDATA[Evolutionary Computations]]></category>
		<category><![CDATA[Triton]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30762</guid>

					<description><![CDATA[Single Instruction, Multiple Data (SIMD) technology enhances performance through parallel data processing on CPUs. SIMD platforms are widely adopted across domains ranging from high-performance computing to AI inference. As modern AI workloads increasingly rely on Python-based kernel frameworks to maintain usability and benefit from automatic tuning, Triton has emerged as a representative solution. However, Triton’s [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Single Instruction, Multiple Data (SIMD) technology enhances performance through parallel data processing on CPUs. SIMD platforms are widely adopted across domains ranging from high-performance computing to AI inference. As modern AI workloads increasingly rely on Python-based kernel frameworks to maintain usability and benefit from automatic tuning, Triton has emerged as a representative solution. However, Triton’s autotuning mechanism, designed primarily for NVIDIA GPUs, fails to effectively exploit the architectural features of SIMD CPUs, creating a significant performance gap on these platforms. To address this problem, we introduce a human–machine collaborative design tailored for Triton kernel tuning on SIMD platforms. This design improves both development efficiency and performance by capturing high-level SIMD optimization intent from human users and integrating it seamlessly into machine framework tuning. Based on this collaborative design, we develop a tuning framework composed of a front-end for user intent recognition and a back-end for user-guided, SIMD-aware tuning. Experiments on x86 and RISC-V platforms show an average performance improvement of 31.7% over native Triton tuning, with tuning cost reduced by up to 75.0%.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30762</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30762</post-id>	</item>
		<item>
		<title>Revealing NVIDIA Closed-Source Driver Command Streams for CPU-GPU Runtime Behavior Insight</title>
		<link>https://hgpu.org/?p=30761</link>
					<comments>https://hgpu.org/?p=30761#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 03 May 2026 20:37:19 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia A40]]></category>
		<category><![CDATA[Performance]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30761</guid>

					<description><![CDATA[For NVIDIA GPUs, CUDA is the primary interface through which applications orchestrate GPU execution, yet much of the logic that realizes CUDA operations resides in NVIDIA&#8217;s closed-source userspace driver. As a result, the translation from high-level CUDA APIs to low-level hardware commands remains opaque, limiting both software understanding and performance attribution. This paper makes that [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>For NVIDIA GPUs, CUDA is the primary interface through which applications orchestrate GPU execution, yet much of the logic that realizes CUDA operations resides in NVIDIA&#8217;s closed-source userspace driver. As a result, the translation from high-level CUDA APIs to low-level hardware commands remains opaque, limiting both software understanding and performance attribution. This paper makes that command path visible. We recover the hardware command streams emitted by NVIDIA&#8217;s closed-source userspace driver with full integrity by leveraging the recently open-sourced kernel driver, instrumenting the memory-mapping path, and installing a hardware watchpoint on the userspace mapping of the GPU doorbell register. This lets us capture complete command submissions at the moment they are committed. Using this methodology, we present two case studies. For CUDA data movement, we identify the DMA submission modes selected by the driver and characterize their raw hardware performance independently of driver overhead through CUDA-bypassing controlled command issuance. For CUDA Graphs, we show that the reduced launch overhead in newer CUDA releases is associated with a smaller command footprint and a more efficient submission pattern. Together, these results show that command-level visibility provides a practical basis for understanding and optimizing GPU middleware behavior, improving performance interpretation, and informing future hardware &#8211; software co-design for CUDA and related accelerator stacks.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30761</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30761</post-id>	</item>
		<item>
		<title>FACT: Compositional Kernel Synthesis with a Three-Stage Agentic Workflow</title>
		<link>https://hgpu.org/?p=30760</link>
					<comments>https://hgpu.org/?p=30760#respond</comments>
		
		<dc:creator><![CDATA[hgpu]]></dc:creator>
		<pubDate>Sun, 03 May 2026 20:37:19 +0000</pubDate>
				<category><![CDATA[Computer science]]></category>
		<category><![CDATA[CUDA]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[CUBLAS]]></category>
		<category><![CDATA[Deep learning]]></category>
		<category><![CDATA[nVidia]]></category>
		<category><![CDATA[nVidia A100]]></category>
		<guid isPermaLink="false">https://hgpu.org/?p=30760</guid>

					<description><![CDATA[Deep learning compilers and vendor libraries deliver strong baseline performance but are bounded by finite, engineer-curated catalogs. When these omit needed optimizations, practitioners substitute hand-written CUDA or CUTLASS, demanding expertise in GPU microarchitecture and C++ template metaprogramming. Recent LLM-based agents target kernel generation in raw CUDA, forcing rediscovery of optimizations already encoded in mature libraries. [&#8230;]]]></description>
										<content:encoded><![CDATA[<p>Deep learning compilers and vendor libraries deliver strong baseline performance but are bounded by finite, engineer-curated catalogs. When these omit needed optimizations, practitioners substitute hand-written CUDA or CUTLASS, demanding expertise in GPU microarchitecture and C++ template metaprogramming. Recent LLM-based agents target kernel generation in raw CUDA, forcing rediscovery of optimizations already encoded in mature libraries. We present FACT (Framework for Agentic CUTLASS Transpilation), a framework that employs a three-stage, agent-driven workflow optimizing PyTorch modules through multi-pattern composition while grounding synthesis in CUTLASS C++. (1) Pattern discovery: an LLM agent inspects the traced graph, matches subgraphs to optimization rules, retrieves vetted examples from an architecture-specific index, and outputs prioritized patterns. (2) Pattern realization: each pattern is implemented as a CUTLASS kernel wrapped in a PyTorch extension, verified, and auto-tuned by sweeping parameters inferred from the CUTLASS hierarchy. (3) Pattern composition: extensions are loaded together into a single composed module for end-to-end benchmarking. We evaluate the workflow using KernelBench&#8217;s evaluation framework and provided modules on an NVIDIA A100. On Level 1, we apply the workflow to three GEMM workloads (square matrix multiply, batched matrix multiply, and large-K matrix multiply). Auto-tuned CUTLASS kernels improve over PyTorch cuBLAS baseline by 1.06x-1.18x. On Level 3 MiniGPT block, composing fused multi-head attention with fused MLP GEMM+GELU yields 2.79x end-to-end speedup. Our work couples agentic graph-level pattern discovery with auto-tuning and a dynamic pattern table, offering a practical path from traced PyTorch to deployable kernels by automating CUTLASS kernel synthesis and auto-tuning.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://hgpu.org/?feed=rss2&#038;p=30760</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">30760</post-id>	</item>
	</channel>
</rss>
