leonarski_fandClaude Opus 5
4e6600a96c
Build Packages / build:windows:nocuda (push) Successful in 14m38s
Build Packages / build:viewer-tgz:cpu (push) Successful in 18m34s
Build Packages / build:viewer-tgz:cuda (push) Successful in 21m44s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 23m0s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 23m41s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 28m36s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 28m38s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 28m54s
Build Packages / build:windows:cuda (push) Successful in 15m45s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 19m56s
Build Packages / XDS test (durin plugin) (push) Successful in 10m58s
Build Packages / build:rpm (rocky9) (push) Successful in 21m16s
Build Packages / Generate python client (push) Successful in 35s
Build Packages / Build documentation (push) Successful in 1m9s
Build Packages / Create release (push) Skipped
Build Packages / build:rpm (rocky8) (push) Successful in 28m17s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 11m39s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 21m36s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 26m33s
Build Packages / DIALS test (push) Successful in 21m38s
Build Packages / XDS test (neggia plugin) (push) Successful in 10m42s
Build Packages / Unit tests (push) Successful in 2h33m11s
CMAKE_CUDA_ARCHITECTURES had no sm_70 entry, and PTX only ever JIT-compiles forwards, so a V100 had no runnable code in the fatbin at all - every kernel launch failed with "no kernel image is available for execution on the device". Append 70 only for a CUDA 12 toolkit: CUDA 13 removed offline compilation for Volta, so an unconditional entry would break the RHEL 9, Ubuntu and Windows builds. 12.8/12.9 still emit it but warn on every .cu, hence -Wno-deprecated-gpu-targets. The append goes after ENABLE_LANGUAGE(CUDA), where the nvcc version is known, matching the existing sm_121 handling. Verified: all 15 CUDA sources compile for sm_70 (including ffbidx, which already guards on __CUDA_ARCH__ >= 700/800), and cuobjdump shows an sm_70 cubin in the built rugnux binary. Consequence worth documenting: a V100 can only run the artefacts built with CUDA 12 - the RHEL 8 packages and the portable Linux .tgz. Document that alongside the minimum NVIDIA driver of every released artefact (525.60.13 for CUDA 12, 580.65.06 for CUDA 13), which applies because the CUDA runtime is linked statically and cuFFT is bundled, so the driver is the only NVIDIA component the target host must supply. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
146 lines
9.1 KiB
Markdown
146 lines
9.1 KiB
Markdown
# Release contents
|
|
|
|
This page describes **what a Jungfraujoch release ships and what each artefact needs on the target
|
|
machine** — which CPU instruction set the binaries were compiled for, which CUDA toolkit they were
|
|
built against, and which runtime libraries are bundled rather than expected from the host.
|
|
|
|
The artefacts in the table below are built and published by the continuous-integration pipeline
|
|
(`.gitea/workflows/build_and_test.yml`) when a tag is pushed. For *how* to install and configure the
|
|
result see [Deployment](DEPLOYMENT.md); for the package-repository URLs see
|
|
[Linux package repositories](REPOSITORIES.md).
|
|
|
|
## Artefacts
|
|
|
|
| Artefact | Distributed via | Contains |
|
|
| --- | --- | --- |
|
|
| `.rpm` / `.deb` packages | [package repositories](REPOSITORIES.md) | The full server stack: `jfjoch` (broker, frontend, FPGA and detector tools), `jfjoch-writer`, `jfjoch-viewer` (incl. the XDS plugin), `jfjoch-driver-dkms` |
|
|
| `jfjoch_viewer-<version>-linux-cuda<major>.tgz`, `...-linux-cpu.tgz` | Gitea release page | Portable Linux viewer package: `jfjoch_viewer`, `rugnux`, `jfjoch_extract_hkl`, `jfjoch_recompress` and the license notices |
|
|
| `jfjoch-viewer-<version>-win64-cuda<major>.exe`, `...-win64-cpu.exe` | Gitea release page | Windows installer with the same four programs, plus the Qt runtime |
|
|
| `jfjoch-writer` `.rpm` / `.deb` | Gitea release page | The writer alone, for a file-writing machine without the rest of the stack |
|
|
| `libjfjoch_xds_plugin.so.<version>` | Gitea release page | XDS HDF5 read plugin (built on RHEL 8); see [Integration with MX software](SOFTWARE_INTEGRATION.md) |
|
|
| `jfjoch-client` | [PyPI](https://pypi.org/project/jfjoch-client/) and the Gitea PyPI index | Generated Python OpenAPI client |
|
|
| Documentation | [Read the Docs](https://jungfraujoch.readthedocs.io) and the `gitea-pages` branch | This documentation set |
|
|
|
|
The FPGA firmware (`.mcs`) images are attached to the release as well. The firmware is stable and is
|
|
carried from version to version, and is rebuilt with Vivado (see [FPGA smartNIC](FPGA.md)) when it
|
|
needs to change — so a card keeps its image across a software upgrade unless the release notes say
|
|
otherwise.
|
|
|
|
## CPU instruction set
|
|
|
|
The architecture flags live in the CI configuration rather than in `CMakeLists.txt`, so a site
|
|
building from source picks its own (`x86-64-v4` on an AVX-512 cluster, `-march=native`, or the plain
|
|
baseline the compiler defaults to). The released binaries are compiled to a fixed floor:
|
|
|
|
| Release | Flags | Minimum CPU |
|
|
| --- | --- | --- |
|
|
| Linux (all packages, and the portable `.tgz`) | `-march=x86-64-v3 -flto=auto` | AVX2 + FMA + BMI2 — Intel Haswell (2013) / AMD Zen (2017) and newer |
|
|
| Windows installer | `/arch:AVX` | AVX — Intel Sandy Bridge (2011) / AMD Bulldozer and newer |
|
|
|
|
The Windows floor is lower because MSVC has no spelling for the `x86-64-v2` level; `/arch:AVX` is
|
|
the nearest one and implies SSE4.1/4.2, which is what actually matters — without it Eigen has no
|
|
vectorised `round` and falls back to a libm call per element. Link-time optimisation is applied on
|
|
Linux only.
|
|
|
|
A binary will fault with an illegal instruction on a CPU below its floor. If you must run on older
|
|
hardware, build from source without the flags.
|
|
|
|
## Operating-system floor
|
|
|
|
The `.rpm` / `.deb` packages are built per distribution (RHEL/Rocky 8 and 9, Ubuntu 22.04 and 24.04)
|
|
and are tied to it. The portable viewer `.tgz` is built on RHEL 8, the oldest supported
|
|
distribution, so its glibc floor is low enough to run on any newer Linux — that is what it is for,
|
|
and why it replaces the per-distro packaging of the viewer on the release page. The Windows
|
|
installer is built and verified on Windows 11.
|
|
|
|
## CUDA and non-CUDA builds
|
|
|
|
Every binary artefact is released in **two variants**, `cuda<major>` and `cpu`. The CUDA variant adds
|
|
the GPU fast-feedback indexer (`ffbidx`), the GPU FFT indexer and GPU image processing; the CPU-only
|
|
variant runs the same pipeline on the CPU with the FFTW indexer, at much lower throughput.
|
|
|
|
The CUDA toolkit used is the one on the corresponding build machine: **CUDA 12** for the RHEL 8
|
|
packages, **CUDA 13** for RHEL 9, Ubuntu and Windows. The major version is part of the artefact and
|
|
repository name, so a download is self-identifying. Building from source needs CUDA 12.8 or newer.
|
|
|
|
**A CUDA build does not require a CUDA machine.** Of the CUDA components only **cuFFT** is linked
|
|
dynamically — the CUDA runtime and the fast-feedback indexer are linked statically — and cuFFT
|
|
itself has no link-time dependency on the NVIDIA driver library. Jungfraujoch asks how many CUDA
|
|
devices are present at start-up and treats "none" (including "no driver installed") as zero GPUs,
|
|
falling back to the CPU path. So a CUDA build starts and runs correctly on a machine with no NVIDIA
|
|
GPU at all, provided the cuFFT runtime can be loaded:
|
|
|
|
- **Portable `.tgz` and Windows installer** — cuFFT is **part of the distribution**, shipped next to
|
|
the executable (on Linux found through an `$ORIGIN` rpath). Nothing else is needed: no CUDA
|
|
toolkit, and on a GPU machine only the NVIDIA driver.
|
|
- **`.rpm` / `.deb`** — cuFFT comes from the distribution's own CUDA packages, so that one
|
|
dependency is managed centrally with the rest of CUDA. Install the cuFFT package alongside, or use
|
|
the `nocuda` repositories on a machine where CUDA is not wanted.
|
|
|
|
The cuFFT runtime is large (the Windows DLL is ~256 MB), so the CUDA artefacts are correspondingly
|
|
bigger than the CPU ones — the other reason for shipping both.
|
|
|
|
On a machine with an NVIDIA GPU, take the CUDA variant: only that one uses the GPU.
|
|
|
|
## GPU generations and the NVIDIA driver
|
|
|
|
A CUDA variant carries compiled device code for a fixed set of GPU generations, and which
|
|
generations those are follows from the CUDA toolkit it was built with. The CUDA runtime is linked
|
|
statically, so the only NVIDIA component the target machine has to supply is the **driver** — there
|
|
is no CUDA-toolkit version requirement on the host.
|
|
|
|
| Artefact | CUDA toolkit | GPU generations | Minimum driver |
|
|
| --- | --- | --- | --- |
|
|
| RHEL 8 packages, portable Linux `.tgz` | 12.9 | Volta (V100) through Blackwell: `sm_70`, `75`, `80`, `86`, `89`, `90`, `100`, `120`, `121` | 525.60.13 |
|
|
| RHEL 9 and Ubuntu packages, Windows installer | 13.x | Turing (T4) through Blackwell: the same list **without** `sm_70` | 580.65.06 (Linux), R580 (Windows) |
|
|
| any `cpu` / `nocuda` variant | — | — | none |
|
|
|
|
**A V100 needs the CUDA 12 build.** CUDA 13 dropped offline compilation for Volta, and the PTX a
|
|
fatbin also carries only ever JIT-compiles *forwards*, so a CUDA 13 artefact contains nothing a V100
|
|
can execute: every kernel launch fails with *no kernel image is available for execution on the
|
|
device*. On a V100 host take the RHEL 8 packages or the portable Linux `.tgz`. Nothing older than
|
|
Volta is supported.
|
|
|
|
Newer GPUs never need a newer build — the highest generation in the list ships PTX as well as SASS,
|
|
which the driver JIT-compiles for a GPU that came out after the release.
|
|
|
|
The minimum driver above is the floor for the whole CUDA *major* version, which is what applies here
|
|
because the CUDA runtime is statically linked
|
|
([CUDA minor version compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html)).
|
|
Newer drivers are always fine; they are backward compatible. A driver from the same release as the
|
|
build toolkit (575.57.08 for the CUDA 12.9 build, 610.43.02 for a CUDA 13.3 one) additionally rules
|
|
out the single caveat of minor version compatibility — a call into a driver API newer than the
|
|
installed driver, which fails with `cudaErrorCallRequiresNewerDriver`.
|
|
|
|
## Windows installer
|
|
|
|
The Windows artefact covers `jfjoch_viewer` and the portable analysis CLIs only; the rest of
|
|
Jungfraujoch (broker, receiver, FPGA host, detector control) is Linux-only.
|
|
|
|
The toolchain bounds of the released installer are:
|
|
|
|
- **Visual Studio 2026** with the C++ (MSVC) toolset. MSVC is not optional — CUDA on Windows builds
|
|
through it — and it is what the release is compiled with.
|
|
- **CUDA Toolkit 13.3** for the `cuda13` variant.
|
|
- **Qt 6.11** for MSVC (`msvc2022_64`), including Qt Charts.
|
|
- Ninja as the generator; zlib and Eigen 3.4 supplied from a build prefix.
|
|
|
|
The installer is generated with NSIS and **bundles the Qt runtime** (via `windeployqt`) and, on the
|
|
CUDA variant, the cuFFT DLL — so the end user installs neither Qt nor a CUDA toolkit. The two
|
|
variants share an install directory and Start Menu group and replace each other (CUDA is a strict
|
|
superset); they are told apart by the installer filename and the Add/Remove Programs entry:
|
|
|
|
| Build | Installer file | Add/Remove Programs |
|
|
| --- | --- | --- |
|
|
| CUDA (default) | `jfjoch-viewer-<version>-win64-cuda<major>.exe` | `Jungfraujoch (CUDA)` |
|
|
| CPU-only | `jfjoch-viewer-<version>-win64-cpu.exe` | `Jungfraujoch (CPU)` |
|
|
|
|
To build the viewer yourself on Windows, see
|
|
[jfjoch_viewer ▸ Building from source on Windows](JFJOCH_VIEWER.md#building-from-source-on-windows).
|
|
|
|
## Licenses
|
|
|
|
Every package variant carries the project license, the third-party manifest and the verbatim
|
|
license texts of the bundled dependencies under `share/doc/jfjoch`. See
|
|
[Third-party software notices](THIRD_PARTY_NOTICES.md).
|