Repository navigation
SCC26: Inline EOS and Riemann-state helpers in GPU kernels - #2095
Closed
AppleChen17 wants to merge 3 commits into
Closed
AppleChen17 wants to merge 3 commits into
AppleChen17 wants to merge 3 commits into
Conversation
nvfortran does not inline GPU routines from another source file into OpenACC kernels, so the EOS and Riemann-state helpers called from modules remain device calls. Move these routines into the Fypp macros EOS_INLINE_PROCS and RS_INLINE_PROCS, and expand a private copy in each calling module. Call sites and formulas are unchanged. In case-optimized builds without a state-dependent EOS, the private f_is_state_dependent returns .false.
|
Claude Code Review Head SHA: a0ee5d5 Files changed:
Findings:
Checked in step 4: eos_inline.fpp, eos_inline_procs.fpp, m_eos.fpp, m_variables_conversion.fpp, riemann_state_inline.fpp, riemann_state_inline_procs.fpp, and the use/include hunks of the simulation modules. |
test_eos_selector requires every eos_* identifier under src/ to be an EOS family constant or a known non-family name, and it matched the include file names eos_inline and eos_inline_procs. Rename the files to inline_eos.fpp and inline_eos_procs.fpp. The generated Fortran is unchanged apart from the file names in comments.
Lines of Code
|
ifx reports error #6580 for the names in "use m_constants, only:" from EOS_INLINE_USE when the same module also has a plain "use m_constants" after it. Move the plain use above the macro in m_acoustic_src and m_ibm. The accessible names, and the generated code, are unchanged.
Collaborator
|
@AppleChen17 This solution is too cumbersome and will not be accepted. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2094. Related: #2088, #2093.
Summary
NVHPC does not inline EOS and Riemann-state helpers into OpenACC kernels when they are defined in another source file, so each call is a real device call (see #2094).
This PR moves 16 EOS and 6 Riemann-state procedures into Fypp macros and expands a private copy in each module that call them from GPU kernels, so the compiler can inline them. Kernels are not restructured and no build option is added. Existing call sites and numerical formulas are unchanged, apart from one case-optimization specialization described below.
On one NVIDIA H200 (NVHPC 26.3, default build flags,
--case-optimization):3D_performance_test(WENO5, HLLC): grind time −11.7%, bit-identical output.3D_IGR_TaylorGreenVortex(IGR, Lax-Friedrichs): grind time −10.5%.This PR is from Team NTHU SCC, participating in the SC26 Student Cluster Competition.
Implementation
src/common/include/inline_eos_procs.fppandsrc/simulation/include/riemann_state_inline_procs.fpp(new) hold the existing procedure bodies in the macrosEOS_INLINE_PROCSandRS_INLINE_PROCS.src/common/include/inline_eos.fppandsrc/simulation/include/riemann_state_inline.fpp(new) provideEOS_INLINE_USE/RS_INLINE_USE, which rename the public procedures onuse, andEOS_INLINE_PRIVATE/RS_INLINE_PRIVATE, which keep the local copies private.m_eosandm_riemann_stateexpand the same macros for their public definitions, so each procedure still has a single source and other callers are unaffected.use, marks the copies private and expands them aftercontains. Existing call sites resolve to the local copies.s_compute_energymoves fromm_variables_conversiontom_eos, andm_variables_conversionno longer re-exports the EOS procedures.m_eosmakess_eos_coefficients,f_has_isentropic_reference,s_reference_curveands_rk4public, because the private copies call them.One intentional specialization: in the private copy of
f_is_state_dependent, a case-optimized build of a case without a state-dependent EOS (#:if MFC_CASE_OPTIMIZATION and not any_state_dependent_eos) returns.false.at compile time, so the state-dependent branches drop out of the kernels. The public version is unchanged, ands_initialize_eos_modulealready aborts when a case does not match the build. All other procedure bodies are identical to master apart from whitespace.Environment
3ef5e1e(baseline) and this PRDevice calls and resource usage
Case-optimized
3D_performance_testbinary, default build flags:3ef5e1eCALLsites to MFC routines, whole binaryCALLsites in HLLC functionsAcross all 486 kernels in this binary, no stack frame grows and 48 shrink. 11 kernels use more registers, and each of them has a smaller stack frame.
The remaining calls are outside the scope of this change.
Performance
NVIDIA H200 (700 W), NVHPC 26.3, default build flags,
--case-optimization, unmodified examples. Mean of five runs interleaved in one allocation. Grind time in ns/gp/eq/rhs.3ef5e1e3D_performance_test(1 GPU, 30 steps)3D_IGR_TaylorGreenVortex(1 GPU, 6366 steps)HLLC kernel in
3D_performance_test, Nsight Compute:3ef5e1eNumerical validation
3D_performance_test: every output file of the last step is bit-identical to master, and two runs of the same binary are identical.3D_IGR_TaylorGreenVortex: master itself is not reproducible run to run. Against master, the last step (step 6366) differs by at most 2.1e-15 relative to the maximum absolute field value.Testing
./mfc.sh test --case-optimization --only <tests>)8551f178551f17: the same)The case-optimized subset contains all 10 state-dependent EOS tests (Mie-Grüneisen, JWL, Vinet, reactive burn) and three tests each for HLLC 1D/2D/3D, HLL, HLLD, LF, IGR, 6-equation, hypoelasticity, Euler-Euler and Lagrangian bubbles, QBMM, IBM, CBC, MHD, viscous, surface tension, chemistry, low-Mach, and other affected paths.
Trade-offs
userename, private, expansion) to benefit. Without it, the module still computes correctly through the public procedures, but keeps the device calls.3D_performance_testbuild, host code (.text) insimulationgrows from 17.1 MB to 17.9 MB (+4.6%), and the whole executable, which is mostly device code, from 564.4 MB to 565.9 MB (+0.26%).cmake/MFCTargets.cmakebuildsm_start_up,m_cbcandm_pressure_relaxationwith-Mnoinline, because of NVHPC 25.x ICEs and the six-equation relaxation miscompile in Stop NVHPC IPO silently miscompiling the six-equation relaxation kernel #1878. That flag stops the cross-file IPO, but not the inlining of same-file procedures, so with this PR the EOS routines named in #1878 (s_phase_coefficients,s_phase_internal_energy,f_pressure) are inlined into the relaxation kernel, andm_cbcgets private copies too. With NVHPC 26.3, and with the earlier revision on 25.9, the six-equation and phase-change tests pass, and so do all CBC tests. #1878 reproduced the miscompile on 25.5 and 25.11, which we cannot run locally, so the CI results on those versions are the relevant check. If they fail, the private copies can be dropped fromm_pressure_relaxationandm_cbc.We are happy to adjust the implementation if reviewers prefer a different approach.
Relationship to #2093
Case-optimized
3D_performance_test, NVHPC 26.3, H200. #2093 is built with--hllc-register-tuning; "#2093 + this PR" is a local merge in which the HLLC module carries both changes, built the same way.CALLsites in the HLLC kernelOther Riemann solvers, each change built on its own (same case and compiler):
CALLsitesContribution Policy
All contributions are expected to demonstrate:
If these expectations are not met, we would prefer to implement the changes ourselves rather than spend time reviewing low-effort submissions.