PantheonSim / Compared with other tools

PantheonSim compared with GPGPU-Sim, Mokka, ZLUDA and other tools

PantheonSim, the GPU simulator for CUDA and ROCm, runs unmodified CUDA and HIP programs on a CPU to check what they do, not how fast they are. Several other projects sit near it and answer different questions. This page says what each is for, in their own words where they have published them, so you can pick the right tool or combine them.

The short version

Different tools answer different questions. Pick by the question you have:

• Does my CUDA or HIP code run correctly, and does it fail where it should, without a GPU? A functional simulator: PantheonSim.
• How many cycles would this kernel take on a modelled GPU design? A cycle-level research simulator: GPGPU-Sim or Accel-Sim.
• Does my Kubernetes scheduling, device plugin or monitoring stack handle GPUs? A mock of the software interfaces around the devices: NVIDIA's Mokka.
• Can I run a CUDA program on a GPU that is not from NVIDIA? A translation layer: ZLUDA, or HIP's back-end for other vendors.
• How fast is it on the real thing? A physical GPU.

What each is for

These descriptions follow what each project says about itself on the page linked. Where a project has changed since, its own page wins. If a statement here is out of date, please open an issue.

Cycle-level research simulators

GPGPU-Sim describes itself as a cycle-level simulator modelling contemporary GPUs and running CUDA or OpenCL workloads. It models how a GPU's hardware behaves cycle by cycle, which is what you want when designing or studying an architecture, and Accel-Sim, according to its README, pairs that model with traces of real SASS execution and reports how closely it correlates with measured hardware. gem5-gpu puts the GPU model inside gem5 so the CPU and GPU can be studied together.

PantheonSim makes the opposite trade. It has no timing, cache or thermal model, so it can say nothing about cycles, stalls or hit rates. In exchange it aims at being a drop-in for software testing: the real nvcc or hipcc builds your program, the runtime and libraries are present under their real names, and nvidia-smi and rocm-smi answer. If you want to know how a new cache would change a kernel's runtime, use a research simulator. If you want your test suite to run on a runner with no GPU, use PantheonSim. They are complements.

Both families need care about how the program links the CUDA runtime. GPGPU-Sim's README says programs must be dynamically linked to the CUDA runtime, and PantheonSim likewise needs nvcc -cudart shared.

Mokka and other mocks of the software around a GPU

NVIDIA's k8s-test-infra describes Mokka as simulating the software contracts around NVIDIA devices rather than the devices themselves, and says real hardware is required for CUDA execution, NCCL, GPUDirect and RDMA data paths. It is built for testing GPU-dependent software in Kubernetes without GPUs: scheduling, the device plugin, telemetry that NVML, nvidia-smi and DCGM read, topology and injected faults.

There is overlap in what a monitoring tool sees: PantheonSim also serves NVML and a drop-in nvidia-smi, with topology, ECC and PCIe fault injection (see the simulated nvidia-smi). The difference is that PantheonSim also runs the CUDA kernels. If your question is cluster plumbing, Mokka is aimed at that and PantheonSim is not a Kubernetes tool. If your question is whether a CUDA program works, Mokka's README says that needs real hardware, and that is where PantheonSim applies.

compute-sanitizer

compute-sanitizer is NVIDIA's own checking suite, included in the CUDA toolkit. Its tools find memory errors, shared memory data races, uses of uninitialized global memory and invalid synchronization. PantheonSim has overlapping checks (out-of-bounds and use-after-free detection, a shared-memory race detector with a scheduler that interleaves warps adversarially, and a strict mode), and it runs without a GPU. NVIDIA's tool is authoritative for what the real hardware and driver do. Use the vendor's tool where you have the hardware, and PantheonSim where you do not or where you want a result that replays the same way every time.

ZLUDA and HIP back-ends: translation layers

ZLUDA's README describes it as a drop-in replacement for CUDA on non-NVIDIA GPUs, running unmodified CUDA applications. A translation layer runs CUDA programs on another vendor's real hardware, so it needs that hardware. HIP's non-AMD back-end goes the other way, letting HIP source target other vendors' GPUs. Both answer the question of running on a GPU you own. PantheonSim answers the question of running when you own none, and says nothing about speed.

Compile-only workflows are a related approach: hipcc or nvcc can build GPU code without a GPU in the machine, which catches compile errors but runs nothing. PantheonSim goes one step further and runs what was built.

Physical GPU CI

Running tests on real GPUs, for example on self-hosted runners with cards, is the reference for performance, numerics on the exact part, and the real driver. It costs hardware and queue time. The usual pattern is to run the fast, broad checks on every pull request on a simulator and keep a run on physical GPUs for a nightly or release job. PantheonSim says the same itself: keep a run on physical GPUs before a release. See CUDA and HIP tests in GitHub Actions.

Where PantheonSim is the wrong tool

• You need performance numbers, power or thermal behaviour. It has no model for any of them.
• Your program links the CUDA runtime statically and you cannot change that. It needs the shared runtime.
• You need NVIDIA's profilers as NVIDIA ships them. Nsight Compute and Nsight Systems are not supported; vgpu ncu is the project's own command line over exact counters.
• You need graphics or ray tracing. OptiX is out of scope.

Questions

Next steps

Try running CUDA without a GPU or ROCm and HIP without an AMD GPU, browse the simulated GPUs, or open the playground. The docs list every command.