enricobuehler
23fa03b051
pf-vkhdr-layer — the sharpest gap: an implicit layer injected into every Vulkan game process, 32 unsafe usages, zero SAFETY comments, own workspace so no lint table reached it, and an explicit missing_safety_doc allow. Now: a [lints] table (unsafe_op_in_unsafe_fn + clippy::undocumented_unsafe_blocks, both deny), the allow removed, every unsafe operation in an explicit block with a real proof (loader layer protocol / Vulkan valid-usage), # Safety docs on the contract-carrying fns, const layout asserts for the SurfaceFormat2Raw mirror, the five helpers with no caller-facing contract demoted to safe fns, and the two redundant `unsafe impl Send` deleted (fn pointers and vk handles are Send intrinsically — the type-check proves it). wdk-probe — 21 unsafe blocks, 12 proofs: the 9 missing SAFETY comments are written (the iddcx_rt.rs DDI slot-dispatch ones are about table population and PFN/index pairing, not pattern fill), the sibling denies added at the crate root, missing_safety_doc allow dropped, # Safety on DriverEntry, and the crate joins windows-drivers.yml's clippy list — it was the only driver crate not in it. pf-clipboard — the undocumented_unsafe_blocks deny moves from host/windows.rs to the crate root so host/wayland.rs (4 blocks), host/mutter.rs (2) and any future backend under host/ are covered on creation. All existing blocks already carry proofs; free today, structural tomorrow. Verified here: pf-vkhdr-layer cargo fmt --check + clippy --release -D warnings at x86_64-pc-windows-msvc. wdk-probe and pf-clipboard compile checks need the WDK/Linux boxes and ride the .133/.25 gate.
pf-vkhdr-layer — HDR Vulkan layer for the virtual display
A tiny Vulkan implicit layer (VK_LAYER_PUNKTFUNK_hdr_inject) that lets Vulkan games enable
HDR while streaming over the punktfunk virtual display.
The problem it solves
On Windows, NVIDIA/AMD Vulkan ICDs do not advertise any HDR color space
(VK_COLOR_SPACE_HDR10_ST2084_EXT, VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT) for a surface that
lives on an IddCx indirect / virtual display — even when Windows "Use HDR" is on and the desktop
is composited at 10-bit. So Vulkan games (Doom: The Dark Ages and the rest of id Tech, Indiana Jones
and the Great Circle, …) query vkGetPhysicalDeviceSurfaceFormatsKHR, find no HDR color space, and
refuse HDR ("This device does not support HDR"). D3D11/D3D12 HDR works on the very same display
because the OS compositor drives it — only the Vulkan WSI enumeration is gated.
This was long believed unfixable from outside the GPU driver (the Apollo/Sunshine/Virtual-Display-
Driver communities all concluded "it's in Windows's kernel"). It isn't: an on-box experiment proved
the ICD happily accepts and presents a forced HDR swapchain on that exact virtual-display
surface (vkCreateSwapchainKHR + vkSetHdrMetadataEXT + present all succeed) — it simply won't
advertise the format. So the whole fix is to add the HDR surface formats to the enumeration the
game queries; once the game requests that swapchain, the ICD honors it. Validated live: Doom: The
Dark Ages enables HDR over the virtual display with this layer.
What it does
- Intercepts
vkGetPhysicalDeviceSurfaceFormatsKHR/...2KHR, calls down to the ICD, and appends{A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT}+{R16G16B16A16_SFLOAT, EXTENDED_SRGB_LINEAR_EXT}(deduped — a no-op on real HDR monitors that already list them). - Self-gates: it only injects when the surface's monitor actually has Windows advanced-color
(HDR) enabled right now (checked via
DisplayConfigGetDeviceInfo/GET_ADVANCED_COLOR_INFO). So it does nothing on SDR sessions/displays — no washed-out "SDR-in-HDR". It tracksVkSurfaceKHR → HWNDby interceptingvkCreateWin32SurfaceKHR. - Everything else is pass-through dispatch chaining (instance + device).
It is shipped as an always-on implicit layer (loads via the registry, so it works regardless of how a game is launched — including via an already-running Steam, which env-based scoping can't guarantee). Because of the self-gate it is inert outside HDR streaming.
Controls
| Variable | Effect |
|---|---|
DISABLE_PF_VKHDR=1 |
Loader-standard off-switch — disables the whole layer for that process. |
PF_VKHDR_EXCLUDE=foo.exe,bar.exe |
Extra exe basenames to skip (in addition to a small built-in kernel-anti-cheat default list: cs2.exe, rainbowsix.exe, …). |
PF_VKHDR_LOG=1 |
Write a debug log to %TEMP%\pf_vkhdr_layer.log. |
Build / install
Standalone crate (own [workspace]), Windows-only cdylib:
cargo build --release # -> target/release/pf_vkhdr_layer.dll
The host installer (packaging/windows/pack-host-installer.ps1 → punktfunk-host.iss) builds it,
lays pf_vkhdr_layer.dll + pf_vkhdr_layer.json into {app}\vklayer, and registers it under
HKLM64\SOFTWARE\Khronos\Vulkan\ImplicitLayers (opt-out task "Install the HDR Vulkan layer").
Manual dev install: drop the DLL + JSON in one directory and add a REG_DWORD value named after the
JSON's full path (data 0) under HKLM\SOFTWARE\Khronos\Vulkan\ImplicitLayers (or HKCU\...).
Confirm with vulkaninfo (Surface section) — HDR10_ST2084_EXT should appear when the display has
HDR enabled.
Notes
- x64 only (the Windows host is x64 only).
- Anti-cheat: the layer is benign (it only adds surface formats; it never touches rendering,
memory, or input) and is signed, but because it's always-on it is present in every Vulkan
process. The built-in exclude list +
PF_VKHDR_EXCLUDE+DISABLE_PF_VKHDRcover kernel-anti- cheat titles you'd rather it stay out of.