Skip to content

tmp(ci): probe Vulkan distribution (windows pack, macOS ICD discovery) -- do NOT merge - #396

Closed
Sunrisepeak wants to merge 2 commits into
mainfrom
tmp/vulkan-dist-probe
Closed

tmp(ci): probe Vulkan distribution (windows pack, macOS ICD discovery) -- do NOT merge#396
Sunrisepeak wants to merge 2 commits into
mainfrom
tmp/vulkan-dist-probe

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Temporary probe for the Vulkan cross-platform design; closed once it has answered. Windows: does mcpp pack carry the deployed vulkan-1.dll and does the packed program start from a clean directory on an image with no system loader? macOS: does the static loader search <exe dir>/vulkan/icd.d, and does MoltenVK enumerate a device on the runner? Runs against #395's branch; touches no index file, so validate does not run.

@Sunrisepeak

Copy link
Copy Markdown
Member Author

Answered; closing. Windows (windows-2022, no system loader): compat.vulkan 1.4.357.3 deploys vulkan-1.dll beside the executable, mcpp pack carries it, and the packed program loads it from a clean directory with PATH = System32 only. macOS (macos-15): the static loader searches <exe dir>/vulkan/icd.d (CoreFoundation's resources dir for an unbundled executable IS the executable's directory); with MoltenVK's dylib beside the executable and a manifest there using a relative library_path, vkCreateInstance succeeds and 1 device (Apple Paravirtual device) enumerates, and the layout keeps working after the whole bin/ is copied elsewhere; with no MoltenVK, vkCreateInstance returns VK_ERROR_INCOMPATIBLE_DRIVER and the process exits 0. Recorded in .agents/docs/2026-09-11-vulkan-cross-platform-closure-design.md.

Sunrisepeak added a commit that referenced this pull request Sep 11, 2026
…the macOS note says how to get a device (#398)

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>
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