Repository navigation
Optimize Zen 4 GEMM macro block sizes (P, Q, R) - #5868
Merged
Merged
Conversation
Vasudeva-bit
marked this pull request as draft
June 25, 2026 13:50
Vasudeva-bit
changed the title
Vasudeva-bit
marked this pull request as ready for review
June 25, 2026 13:51
Collaborator
|
Looks like the DYNAMIC_ARCH part is not working as expected, but I'm currently on my phone and reading the CI logs is a bit tedious |
Contributor
Author
|
Yes, I shall have a look at the logs soon. No problem, I shall let you know if I am stuck. |
hhashimoto135
pushed a commit
to hhashimoto135/OpenBLAS
that referenced
this pull request
Sep 22, 2026
The x86-64 init_parameter() of kernel/setparam-ref.c ends with a block that no core #ifdef guards. It reads the running host's CPUID and, for an AuthenticAMD part with l3_kb % 32768 == 0, l2_kb == 1024 and AVX512F, raises sgemm_p/q to 384/512 and dgemm_p/q to 512/512 in whichever TABLE_NAME is being initialised. That is the Zen 4 tuning of upstream PR OpenMathLib#5868, and it runs after force_coretype(), so OPENBLAS_CORETYPE swaps the kernel and leaves the host-derived blocking in place. driver/level3/level3.c caps the k a kernel sees at GEMM_Q, and the kernels without AVX512 pack into a fixed buffer on their own stack sized for their own GEMM_DEFAULT_Q - kernel/x86_64/dgemm_kernel_4x8_haswell.S reserves L_BUFFER_SIZE against DGEMM_DEFAULT_Q 128 under WINDOWS_ABI. A GEMM_Q of 512 breaks that invariant and the kernel writes past its frame. On a 9800X3D, which matches the CPUID gate, a plain cblas_dgemm(CblasColMajor, N, N, 37, 65, 1000, 1.0, a, 37, b, 1000, 0.0, c, 37) with OPENBLAS_CORETYPE=Haswell faults in dgemm_kernel_HASWELL. Neither the packed GEMM extension nor bfloat16 is involved; Core2, Prescott and Barcelona fail the same way in sgemm, and the first failing k for each core sits just above that core's own GEMM_DEFAULT_Q. The heap scratch was never the problem: sa and sb fit BUFFER_SIZE on every core. An x86-64-v3 machine cannot reach this, because the gate needs AuthenticAMD and AVX512F together, and a genuine Haswell or Zen keeps a GEMM_DEFAULT_Q of 128 against a measured threshold of 142. A NO_AVX512 build of this library can, without any environment variable, because gotoblas_COOPERLAKE is then a macro for gotoblas_HASWELL. It also reaches the core forcing that this branch documents for testing the bfloat16 fallback. setparam-ref.c is compiled once per core, and only under DYNAMIC_ARCH, and the generated kernel_config/<CORE>/config_kernel.h defines that core's macro and no other, so restricting the override to COOPERLAKE, SKYLAKEX and SAPPHIRERAPIDS can be spelled at compile time. Cooperlake and SkylakeX keep 384/512 and 512/512; Haswell and Zen fall back to their own parameters. A static build is unaffected either way: it uses driver/others/parameter.c, whose x86-64 path never assigns *gemm_q. Upstream reached the same whitelist in PR OpenMathLib#6027 but compares gotoblas_corename() with "cooperlake", "skylakex" and "sapphirerapids", while the x86-64 corename[] table in driver/others/dynamic.c holds "Cooperlake", "SkylakeX" and "SapphireRapids". The strcmp never matches, so that patch disables the tuning everywhere. A run time test on that name would also inherit the loop bound of force_coretype(), which stops at corename[25] and can never report "SapphireRapids". See change/openblas-zen-blocking-override.md, and upstream issues OpenMathLib#6013, OpenMathLib#6021 and OpenMathLib#6026. The 460 tests of the consuming project now pass under every one of unset, Haswell, Zen, SkylakeX, Cooperlake, Nehalem, SandyBridge, Core2, Prescott and Barcelona; before this, Haswell and Zen died in the packed double tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QhYbD3vesgHtUGtaG9SvbX
This was referenced Oct 15, 2026
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.
Zen 4 Cache Boundary Optimisations (uses CooperLake Micro Kernels) #5837
Description:
This PR introduces targeted cache geometry overrides (
P,Q,Rparameters) for the Zen 4 architecture. Parameters were derived using Bayesian Optimization (Optuna) to perfectly align matrix panel footprints with the physical 1MB L2 and 32MB L3 limits of the Zen 4 CCX.1. Successful Optimisations (Implemented)
These standard GEMM variants demonstrated absolute GFLOPs scaling over the baseline OpenBLAS generic fallbacks. These are the configurations included in this patch.
(P, Q, R)384, 512, 5936512, 512, 2288160, 480, 528176, 256, 15202. Discarded
(P, Q, R)368, 712, 4544168, 376, 3920192, 256, 1904