enricobuehler
c06ee55b61
ci / bun-nix (pull_request) Successful in 38s
apple / swift (pull_request) Successful in 1m31s
apple / screenshots (pull_request) Skipped
ci / web (pull_request) Successful in 2m11s
ci / docs-site (pull_request) Successful in 2m21s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m44s
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m10s
ci / rust-arm64 (pull_request) Successful in 6m29s
android / android (pull_request) Successful in 7m44s
ci / rust (pull_request) Canceled after 9m40s
nix / flake (pull_request) Canceled after 9m38s
The Intel Arc refusal moved one step down the caps query and stopped again: the coincide NV12 entry does not advertise SAMPLED. That sentence is punktfunk's, not the driver's, and the last two times a conclusion was drawn from a sentence of ours the conclusion was wrong. So --probe-decode now prints the driver's own answers instead. For every profile the client can negotiate (H.264 High, H.265 Main and Main 10, AV1 Main 8- and 10-bit) it asks vkGetPhysicalDeviceVideoFormatPropertiesKHR in six usage combinations — the three the image pools really create with, plus DPB|DST without sampling, SAMPLED alone and DST alone, which are what localise a refusal to a half. Each answer is printed as the driver gave it: format, usage and create flags named AND in hex with unrecognised bits called out, image type, tiling. A failed query prints its VkResult rather than vanishing into an empty list. It goes through pf-vkdecode's own query rather than a copy of it, which meant splitting query_formats into a physical-device form — the call never needed the VkDevice the old signature demanded. VideoFormat gains imageType and imageTiling to carry the whole record; VUID-VkImageCreateInfo-pNext-06811 compares both for equality, so they were being assumed rather than read. And because a driver that under-reports usage would be indistinguishable from one that genuinely lacks it, the probe asks a second, independent question — vkGetPhysicalDeviceImageFormatProperties2 over the same profile list — and prints it only where the two disagree. A disagreement is the finding. No behaviour change to any decode path: derivation reads the same fields it did.
63 lines
2.9 KiB
TOML
63 lines
2.9 KiB
TOML
[package]
|
|
name = "pf-presenter"
|
|
description = "The Vulkan session presenter — SDL3 window, ash swapchain, frame present, input capture; the stage-2 presenter of punktfunk-planning linux-client-rearchitecture.md"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
rust-version.workspace = true
|
|
license.workspace = true
|
|
authors.workspace = true
|
|
repository.workspace = true
|
|
|
|
# Same Linux+Windows gating as the rest of the client stack (dmabuf import is the one
|
|
# Linux-only module — see lib.rs).
|
|
[target.'cfg(any(target_os = "linux", windows))'.dependencies]
|
|
# `default-features = false`: the PyroWave decode backend is turned on through THIS crate's own
|
|
# `pyrowave` feature (which re-exports it below), never by inheriting the dependency's default.
|
|
# Otherwise a consumer that deliberately builds us without `pyrowave` still drags the vendored
|
|
# C++ in — fatal on Windows ARM64, where Granite has no SIMD path.
|
|
pf-client-core = { path = "../pf-client-core", default-features = false }
|
|
punktfunk-core = { path = "../punktfunk-core", features = ["quic"] }
|
|
# `--probe-decode` reports the driver's own video-format answers through pf-vkdecode's
|
|
# query rather than a second copy of it — a probe that keeps its own copy is a probe
|
|
# that eventually disagrees with the code it exists to explain (VIDEO_BASE's doc says
|
|
# the same thing about the extension list). Already in the tree via pf-client-core;
|
|
# named here because setup.rs calls it directly.
|
|
pf-vkdecode = { path = "../pf-vkdecode" }
|
|
|
|
# `loaded` dlopens libvulkan at runtime (no link-time dependency — GPU-less boxes still
|
|
# start and fail into a clean error; on Windows vulkan-1.dll is a GPU-driver component).
|
|
# `ash` on sdl3 types SDL_Vulkan_CreateSurface with ash 0.38 handles so the surface
|
|
# hands over without transmutes.
|
|
ash = { version = "0.38", features = ["loaded"] }
|
|
|
|
async-channel = "2"
|
|
anyhow = "1"
|
|
tracing = "0.1"
|
|
|
|
# Linux links the system SDL3; Windows builds it from source (same choice as the rest
|
|
# of the workspace's Windows SDL consumers).
|
|
[target.'cfg(target_os = "linux")'.dependencies]
|
|
sdl3 = { version = "0.18", features = ["hidapi", "ash"] }
|
|
|
|
[target.'cfg(windows)'.dependencies]
|
|
sdl3 = { version = "0.18", features = ["hidapi", "ash", "build-from-source"] }
|
|
# Window branding only (win32.rs): the exe-embedded icon onto the SDL window's title
|
|
# bar/taskbar (WM_SETICON) and the shared AppUserModelID for unpackaged runs, so the
|
|
# shell and the session window group as ONE taskbar app across the visibility handoff.
|
|
windows-sys = { version = "0.61", features = [
|
|
"Win32_Foundation",
|
|
"Win32_Storage_Packaging_Appx",
|
|
"Win32_System_LibraryLoader",
|
|
"Win32_UI_Shell",
|
|
"Win32_UI_WindowsAndMessaging",
|
|
] }
|
|
|
|
[features]
|
|
# PyroWave planar present path (the wired-LAN wavelet codec) — forwards to the decode
|
|
# backend in pf-client-core; ON by default, matching pf-client-core's default.
|
|
default = ["pyrowave"]
|
|
pyrowave = ["pf-client-core/pyrowave"]
|
|
|
|
[lints]
|
|
workspace = true
|