GitLab

Add gpu-hpl and gpu-hpl-mxp micro benchmarks backed by rocHPL and rocHPL-MxP.

Implemented a shared GPU HPL base that:
- Generates per-workload HPL dat files and parses the corresponding output files.
- Supports common HPL inputs such as process grid, matrix size, block size, broadcast topology, warmup, iterations, and reduce operator.
- Adds rocHPL-specific tuning parameters for gpu-hpl.
- Formats metric keys from input-derived workload attributes.
- Reports `flops`, `time`, and `tests_pass` metrics with warmup-aware aggregation.

Add benchmark registrations, parser tests, sample output fixtures, documentation, and recommended configurations for gpu-hpl and gpu-hpl-mxp.

Update rocHPL and rocHPL-MxP third-party integration with build patches, install targets, and SuperBench run helper scripts.

Also update gpu-hpcg metric naming to use flops instead of gflops, remove standalone domain/verification-style metrics from the documented metric surface, and refresh Hygon HPCG documentation/config references accordingly.

Summary

The gpu_stream benchmark has NVIDIA-specific dependencies that prevent
it from compiling on ROCm 6.3+. This change makes it CUDA-only,
gracefully skipping the build with a warning on non-NVIDIA
  environments.

  Problem

The gpu_stream benchmark fails to compile on ROCm 6.3+ due to multiple
NVIDIA-specific dependencies:

1. nvml.h — NVIDIA Management Library header, used for querying actual
memory clock rates. No HIP equivalent. Referenced in gpu_stream.cu and
gpu_stream_utils.hpp.
2. cuda.h in headers — Three .hpp files (gpu_stream.hpp,
gpu_stream_kernels.hpp, gpu_stream_utils.hpp) directly include <cuda.h>
and <cuda_runtime.h>. These headers are not processed by hipify-perl
(only
  .cu source files are), so they fail to resolve on ROCm.
3. Deprecated hipDeviceProp_t struct fields — The code accesses
memoryBusWidth, memoryClockRate, and ECCEnabled from the device
properties struct. These fields were removed from hipDeviceProp_t in
ROCm
    6.3, causing compilation errors after hipification.

The existing ROCm path was marked as incomplete (# TODO: test for ROC)
and was never fully functional on recent ROCm versions.

  Changes

- Removed the non-functional ROCm/HIP build path from
gpu_stream/CMakeLists.txt
- When CUDA is not found, prints a warning and returns gracefully
instead of attempting a broken hipify build or raising FATAL_ERROR
- No changes to the NVIDIA/CUDA build path — it continues to work as
before

  Impact

   - NVIDIA builds: No change — gpu_stream builds and installs normally
- ROCm builds: gpu_stream is skipped with a warning message. Previously
it would fail the entire make cppbuild step, blocking the Docker image
build
- Other benchmarks: Unaffected — build.sh continues to the next
benchmark after gpu_stream returns
Co-authored-by: Hongtao Zhang <hongtaozhang@microsoft.com>

## Description
This affects all PRs running `python3 setup.py lint` on the Python 3.12
CI job.

## Root Cause

Comparing the last successful cpu-unit-test build (58939, Mar 25) with a
recent failing build (58996, Apr 14), the Python 3.12 "Install
dependencies" step shows:

| Package | Successful (Mar 25) | Failing (Apr 14) |
|---|---|---|
| `setuptools-scm` | < 10.0 (no `vcs-versioning` dep) | 10.0.5 (requires
`vcs-versioning`) |

`setuptools-scm` 10.0.5 was released between the two runs and added
`vcs-versioning` as a new dependency. The `setup_requires` mechanism in
`setup.py` does not install transitive dependencies, so `vcs-versioning`
is missing at runtime.

The successful build lint log (Python 3.12): "ModuleNotFoundError: No
module named 'vcs_versioning'"

This affects all PRs running `python3 setup.py lint` on the Python 3.12
CI job.

## Changes

- Add `vcs_versioning` explicitly to `setup_requires` in `setup.py` so
it is available when `setuptools-scm` is imported during `setup.py`
execution.

## Testing

Verified that `setuptools-scm` 10.0.5 declares `vcs-versioning` as a
dependency, and the CI failure matches the missing transitive dependency
pattern.
Co-authored-by: Hongtao Zhang <hongtaozhang@microsoft.com>

* Update gpu-hpcg metrics to encode process and problem shape

* Fix tests

- Add BW150 config
- Update BW1000 config
- Merge summary rules

- Add `numactl` support for local runner modes, including `cpunodebind`, `membind`, and `physcpubind`.
- Add `gpu_affinity` resolution through `sb node topo --get gpu-numa-affinity --gpu-id`.
- Add `sb node topo` support for GPU NUMA topology queries.
- Update BW1000 config to use the new local `numactl` semantics.
- Document the new `numactl` mode fields and limitations.

* Update mem-bw to use BandwidthTest

* Update config and format code

* Support GPU system info collection via hy-smi

* Fix typos in docs

* Fix some lint warnings
* Exclude some paths in cpplint
* Fix some tests and formatting

Adds opt-in deterministic training mode to SuperBench's PyTorch model
benchmarks. When enabled --enable-determinism. PyTorch deterministic
algorithms are enforced, and per-step numerical fingerprints (loss,
activation means) are recorded as metrics. These can be compared across
runs using the existing sb result diagnosis pipeline to verify bit-exact
reproducibility — useful for hardware validation and platform
comparison.
 
Flags added - 

--enable-determinism
--check-frequency: Number of steps after which you want the metrics to
be recorded
--deterministic-seed

Changes - 

Updated pytorch_base.py to handle deterministic settings, logging.
Added a new example script: pytorch_deterministic_example.py
Added a test file: test_pytorch_determinism_all.py to verify everything
works as expected.

Usage - 

Step 1: Run 1 - Run with --enable-determinism and the necessary metrics
will be recorded in the results-summary.jsonl file
Step 2: Generate the baseline file from the Run 1 results using - sb
result generate-baseline
Step 3: Run 2 - Run with --enable-determinism and the necessary metrics
will be recorded in the results-summary.jsonl file on a different
machine (or the same machine)
Step 4: Run diagnosis on the results generated from the 2 runs using the
- sb result diagnosis command

Note - 
1. Make sure all the parameters are constant between the 2 runs 
2. Running the diagnosis command requires the rules.yaml file

---------
Co-authored-by: Aishwarya Tonpe <aishwarya.tonpe25@gmail.com>
Co-authored-by: Ubuntu <rdadmin@HPCPLTNODE0.n3kgq4m0lhoednrx3hxtad2nha.cdmx.internal.cloudapp.net>

- Get ansible_user_dir from facts
- Get hostname from facts
- Update NODE_RANK expression

Configure GitHub Pages