Note that the GPU dialect includes both host side as well as device operations. This only consider device side operations. Goal of the dialect The GPU dialect is used to target GPUs while being agnostic to APIs and target. Therefore it is designed to abstract hardware specific details. To target c…

[image] ThomasRaoux: This proposal is for adding a new Nvidia/PTX Dialect I’m a bit confused here: are you really adding a new dialect or just carving out a set of operations in the gpu dialect that you’ll prefix with mma. to somehow conceptually “namespace” them?

[image] nicolasvasilache: One question that comes to mind is whether you see some of these distribution abstractions potentially also percolating up to the vector dialect? I think so, this is still under progress but I’m trying to build some distribution abstraction, the distribution part is …

[image] ThomasRaoux: Those operations are similar to the exiting SubgroupMmaComputeOp and SubgroupMmaLoadMatrixOp however they would be explicitly define how the matrices are mapping onto the warp lanes. This will allow to not use an opaque type for matrices and this will allow generating more …

[image] herhut: [image] ThomasRaoux: Those operations are similar to the exiting SubgroupMmaComputeOp and SubgroupMmaLoadMatrixOp however they would be explicitly define how the matrices are mapping onto the warp lanes. Could you explain a bit more what the specific differences would be? …

[image] ThomasRaoux: The proposal is to add a new dialect. A new namespace where target specific ops can be added would be enough if you think this is better but I haven’t seen any precedent for it. What part is unclear? OK! The part that wasn’t clear to me was that your example showed gpu.mm…

Since there doesn’t seem to be any objections so far, I sent a patch introducing the new dialect for review: https://reviews.llvm.org/D123266

[image] ThomasRaoux: In some cases there is a large abstraction gap, making the lowering non trivial and preventing us from doing higher level transformation based on hardware details. This part (“preventing us from doing higher-level transformation”) isn’t entirely clear to me. An example he…

[image] bondhugula: This part (“preventing us from doing higher-level transformation”) isn’t entirely clear to me. An example here would help One example is supporting a way to access swizzled shared memory like cutlass does (slide 37-48): s21745-developing-cuda-kernels-to-push-tens…

[image] ThomasRaoux: [image] bondhugula: This part (“preventing us from doing higher-level transformation”) isn’t entirely clear to me. An example here would help One example is supporting a way to access swizzled shared memory like cutlass does (slide 37-48): https://developer.download.…

[RFC] Add NV-GPU dialect (HW specific extension of GPU dialect for Nvidia GPUs)

MLIR

ThomasRaoux April 5, 2022, 8:04pm 8

Ah yes my bad, I pasted the version of the draft that is currently in the GPU dialect but it would be a different dialect prefix indeed.

Topic		Replies	Views
[RFC] Cleaning the GPU dialect MLIR gpu	54	2612	February 17, 2026
[RFC] Add XeGPU dialect for Intel GPUs MLIR	21	12982	February 22, 2024
[RFC] Add GEN dialect for Intel GPUs MLIR	64	4629	May 3, 2024
[Abandoned][RFC] AVX512-specific Dialect for implementing and benchmarking XNNPack in MLIR MLIR	22	2178	March 4, 2020
Move / Remove `vcix` dialect MLIR riscv	48	1747	July 3, 2025

[RFC] Add NV-GPU dialect (HW specific extension of GPU dialect for Nvidia GPUs)

Related topics