diag(vkdecode): log the driver's video capabilities verbatim
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m9s
ci / bun-nix (pull_request) Successful in 30s
ci / web (pull_request) Successful in 1m20s
apple / swift (pull_request) Successful in 1m28s
apple / screenshots (pull_request) Skipped
ci / docs-site (pull_request) Successful in 1m51s
ci / rust-arm64 (pull_request) Successful in 2m44s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m46s
android / android (pull_request) Successful in 4m16s
ci / rust (pull_request) Successful in 4m52s
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m9s
ci / bun-nix (pull_request) Successful in 30s
ci / web (pull_request) Successful in 1m20s
apple / swift (pull_request) Successful in 1m28s
apple / screenshots (pull_request) Skipped
ci / docs-site (pull_request) Successful in 1m51s
ci / rust-arm64 (pull_request) Successful in 2m44s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m46s
android / android (pull_request) Successful in 4m16s
ci / rust (pull_request) Successful in 4m52s
Nothing in the caps module logged anything, so when a device refused with "advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" there was no way to separate two very different situations that present identically as a zero: the driver filling the chain and genuinely declaring no DPB mode, versus our own pNext chain never reaching VkVideoDecodeCapabilitiesKHR at all. Printing the BASE VkVideoCapabilitiesKHR beside the decode flags is the discriminator. A populated max_dpb_slots next to decode_flags: 0 means the driver traversed the chain and answered; zeros across both mean the query never landed and the refusal is ours, not the driver's. Raised by the Intel Arc result on .221, where I concluded "driver bug" on the strength of our own code's report — which is precisely the circular reasoning this line exists to break.
This commit is contained in:
@@ -308,6 +308,26 @@ pub(crate) unsafe fn query_h265_caps(
|
||||
let decode_flags = decode_caps.flags;
|
||||
let max_level_idc = h265_caps.max_level_idc;
|
||||
|
||||
// What the driver ACTUALLY said, before any of our interpretation. Nothing in this
|
||||
// module logged, so a refusal downstream ("advertises neither COINCIDE nor DISTINCT")
|
||||
// was indistinguishable from our own chain never reaching the struct: both present as
|
||||
// a zero. Printing the BASE capabilities beside the decode ones is the discriminator —
|
||||
// a populated `max_dpb_slots` next to `decode_flags: 0` means the driver filled the
|
||||
// chain and genuinely declared no DPB mode; zeros across both mean the query never
|
||||
// landed. Debug rather than info: one line per profile per session, wanted only when
|
||||
// someone is asking this exact question.
|
||||
tracing::debug!(
|
||||
codec = "H.265",
|
||||
?capability_flags,
|
||||
?decode_flags,
|
||||
max_dpb_slots,
|
||||
max_active_reference_pictures,
|
||||
?min_coded_extent,
|
||||
?max_coded_extent,
|
||||
?picture_access_granularity,
|
||||
"driver video capabilities, verbatim"
|
||||
);
|
||||
|
||||
// The three queries carry the REAL creation usages (SAMPLED included for the
|
||||
// presenter-facing roles) so the answers validate the images the pools build.
|
||||
let decode_profile = DecodeProfile::H265(key);
|
||||
|
||||
Reference in New Issue
Block a user