Skip to content

feat(khronos.vulkan-hpp): 1.4.357.1 follows compat.vulkan 1.4.357.3; the macOS note says how to get a device - #398

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/vulkan-hpp-follows-loader
Sep 11, 2026
Merged

feat(khronos.vulkan-hpp): 1.4.357.1 follows compat.vulkan 1.4.357.3; the macOS note says how to get a device#398
Sunrisepeak merged 1 commit into
mainfrom
feat/vulkan-hpp-follows-loader

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

What

  • khronos.vulkan-hpp 1.4.357.1 — same headers, pin → compat.vulkan 1.4.357.3; vulkan-hpp-module → 1.4.357.1
  • compat.vulkan macOS runtime comment — what was measured about getting a device (no behaviour change)

Why it is separate from #395

vulkan-hpp-module redirects only khronos to this checkout, so compat resolves from the published index — which had no 1.4.357.3 until #395 merged. A second project index is still refused on mcpp 2026.9.11.2. So: merge #395 → republish → this.

On #395's windows-2022 leg this member failed as predicted (resolved compat.vulkan 1.4.357.0 → 0xC0000135). This PR is judged by that leg passing.

macOS note, measured on macos-15 (#396)

result
no MoltenVK exit 0, VK_ERROR_INCOMPATIBLE_DRIVER, 0 devices — no crash
libMoltenVK.dylib + vulkan/icd.d/MoltenVK_icd.json (relative library_path) beside the executable 1 device, and still 1 after moving the directory
VK_DRIVER_FILES 1 device

Portability enumeration must be enabled by the program. mcpp deploying those files: mcpp-community/mcpp#615.

…the macOS note says how to get a device

KHRONOS.VULKAN-HPP 1.4.357.1 -- the same Vulkan-Headers tarball, pinned to
compat.vulkan 1.4.357.3, whose Windows artifact carries the loader DLL. A new
version rather than a moved pin, because an installed copy records the pin it
resolved with. `vulkan-hpp-module` moves to it.

This is the half of #395 that could not be verified in #395 itself: the member
redirects only the `khronos` namespace to this checkout, so `compat` came from
the published index, which did not have 1.4.357.3 until #395 merged. Redirecting
`compat` as well is still refused on mcpp 2026.9.11.2 ("≥2 project-level index
repos is a known xlings resolution gap"), so the order had to be: merge #395,
republish, then this. On #395's own `windows-2022` leg the member failed exactly
as predicted (it resolved compat.vulkan 1.4.357.0 and died with 0xC0000135);
this change is judged by that leg passing.

COMPAT.VULKAN, macOS -- a comment, no behaviour change. The block said only that
the ICD is MoltenVK. It now records what was measured on macos-15 (#396):
nothing crashes without MoltenVK; a device enumerates when libMoltenVK.dylib
and a relative-path manifest sit in <executable dir>/vulkan/icd.d, which the
static loader searches first, and that layout survives being moved; or through
VK_DRIVER_FILES; and in both cases only with portability enumeration enabled.
What mcpp would need to place those files is mcpp-community/mcpp#615.

Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com>
@Sunrisepeak
Sunrisepeak merged commit 194b3c6 into main Sep 11, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant