TheRock/rocm-systems/projects/rocprofiler-compute/docs/conceptual/rdna/system-speed-of-light.rst

.. meta::
    :description: ROCm Compute Profiler performance model: System Speed-of-Light (RDNA)
    :keywords: ROCm Compute Profiler, RDNA, gfx115x, system speed of light

.. _sys-sol-rdna:

=====================
System Speed-of-Light
=====================

This section details the System Speed-of-Light metrics for RDNA3.5 (gfx115x) with the
shipped gfx115x analysis configuration. System Speed-of-Light is a high-level summary of workload performance. It highlights the most important
metrics for how your workload is performing on the target GPU, so you can spot
bottlenecks before diving into block-specific panels.

The ``VALU FLOPs`` rows use aggregate VALU instruction counters, which include FP16,
FP32, and FP64 contributions together. Wave Matrix Multiply-Accumulate (WMMA) instructions follow a separate Instruction Set Architecture (ISA)
path and are not broken out in this panel.

Wavefronts and FLOPs accounting
-------------------------------

RDNA3.5 supports both Wave32 (wavefront size 32: primary execution mode) and Wave64 (wavefront size 64).
The wavefront size is fixed per kernel at compile time. The profiler reads
``$wave_size`` from the hardware specs reported by ``rocminfo``, however a given
kernel may also been compiled for the other size. When that happens, treat the
peak rates here as approximations. The ``VALU FLOPs`` row in this panel scales as
``wave_size * SQ_INSTS_VALU_sum / time``.

.. _rdna-dual-issue-valu:

Dual-issue VALU (VOPD)
----------------------

RDNA3.5 add a dual-issue path to the VALU. A pair of independent
VALU operations can be encoded into a single instruction and issued together in
the same cycle. The RDNA ISA refers to this encoding as Vector Operation - Dual (VOPD). Hardware
accepts the pairing only when register, opcode, and operand constraints are
satisfied, and the compiler emits VOPD when those constraints hold.

When dual-issue runs successfully, peak VALU throughput per compute unit (CU) per cycle
doubles relative to single-issue: ``FP32`` from 128 to 256 FLOPs/CU/cycle, and
packed ``FP16`` from 256 to 512 FLOPs/CU/cycle.

The aggregate ``VALU FLOPs`` row in this panel uses the ``FP32`` single-issue Fused Multiply-Add (FMA)
ceiling (128 FLOPs/CU/cycle) as the peak. A workload that issues VOPD heavily,
or that runs packed FP16, can therefore report a percentage of peak above
100%. To gauge how much of the throughput is coming from VOPD, inspect the
``Instructions - Dual VALU (VOPD)`` row on the :doc:`wgp` panel, which counts
``SQ_INSTS_DUAL_VALU_WAVE32``.

Peak theoretical VALU rates
---------------------------

The values below are per CU, before multiplying by the CU count and the shader
clock. These values anchor the percentage of peak reported for the FLOPs related rows.

* FP32 FMA single-issue: 128 FLOPs/CU/cycle. Two SIMD32 lanes per CU
  (``$simd_per_cu``), Wave32 (``$wave_size`` 32), multiplied by two for FMA.
* FP32 VOPD dual-issue: 256 FLOPs/CU/cycle. Paired dual-VALU instructions such
  as ``V_DUAL_ADD_F32`` and ``V_DUAL_MUL_F32``.
* FP16 packed FMA single-issue: 256 FLOPs/CU/cycle. Packed FP16 runs at twice
  the FP32 rate.
* FP16 packed VOPD dual-issue: 512 FLOPs/CU/cycle. Dual-issue packed FP16
  pairings.
* FP64 FMA: 4 FLOPs/CU/cycle. RDNA3.5 runs FP64 FMA at 1/32 of the FP32
  single-issue FMA rate.
* Mixed FP32 single-issue with FP16 packed dual-issue (illustrative ceiling):
  about 384 FLOPs/CU/cycle combined (128 + 256).

Scaling and clocks
------------------

``$cu_per_gpu`` is the total CU count from system info, not WGP count. On RDNA3.5,
each WGP pairs two CUs, so CU count is roughly twice the WGP count - since
``$cu_per_gpu`` reflects active CUs discovered at runtime (rather than just doubling
a fixed WGP count). Peak FLOPs scale with CUs. ``$max_sclk`` is the shader/engine
clock in MHz from profiler system specs.

Bandwidth and cache rows
------------------------

The throughput rows for GL0 (TCP Cache), GL1, GL2, and SQC use heuristic ceilings that are
not anchored to a single public RDNA3.5 table, so the percentage of peak
reported for these rows is indicative rather than exact. The memory hierarchy
runs GL0 (TCP Cache) -> GL1 -> GL2 -> system memory via GCEA. Each level's
ceiling is one peak transfer per cycle, scaled by instance count and
``$max_sclk``:

* GL0 (TCP Cache): One 128-byte cacheline per cycle per CU --
  ``$cu_per_gpu * 128 B/cycle * $max_sclk``
* GL1: One 128-byte request per cycle per GL1C instance -- ``($cu_per_gpu / 8) * 128 B/cycle * $max_sclk``
* GL2: One 128-byte request per cycle per L2 bank --
  ``$total_l2_chan * 128 B/cycle * $max_sclk``
* SQC (scalar data cache and instruction cache): One 64-byte Texture Cache (TC) request per
  cycle per SQC instance -- ``$sqc_per_gpu * 64 B/cycle * $max_sclk``

.. Note::

  * For AMD Instinct GPUs (CDNA-CDNA4), see :doc:`../cdna/system-speed-of-light`.
  * Other gfx115x metric tables follow the RDNA3 hierarchy under :doc:`rdna-performance-model` (nested under :doc:`shader-engine` as :doc:`spi`, :doc:`wgp`, :doc:`gl0-cache`, :doc:`gl1-cache`; then :doc:`gl2-cache`, :doc:`gcea`, :doc:`command-processor`, :doc:`grbm`).

.. warning::

   Theoretical peaks use the maximum clock frequency reported for the GPU (for
   example via ``rocminfo``). That may not match sustained clocks under your
   workload.

.. tab-set::

  .. tab-item:: RDNA3.5 (gfx115x)
      :selected:

      .. jinja:: sys-sol-gfx115x
         :file: _templates/metrics_table.j2