You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This means that, effectively, passing HDR metadata puts the display into ST.2084 mode even when the colorSpace chosen for the swapchain is COLOR_SPACE_SRGB_NONLINEAR_KHR, a contradiction. As is, this implementation basically requires users hard-coding undocumented vendor-specific behavior, and leaves important questions unresolved (e.g. what primaries are in use).
The correct way forward, I think, would be to expose support for VK_EXT_swapchain_colorspace, add VK_COLOR_SPACE_HDR10_ST2084_EXT as a valid swapchain color space type, and set the HDMI EOTF depending on this color space.
The text was updated successfully, but these errors were encountered:
New feature and improvement
* Enable extension VK_EXT_load_store_op_none
* Enable extension VK_KHR_zero_initialize_workgroup_memory
* Add exclusion for implicit external synchronization if there is no layout transition
* Update Khronos Headers to 1.2.188
* Valhiem shader optimization
Issue fix
* [XGL issue #126] Switchable graphics layer filters out cards AMDVLK dropped support for
* Heavy flickering observed while performing ALT-TAB in Ghost Recon: Breakpoint Vulkan
* Corruption when turning on DebugOverlayEnable
* RPCS3 Corruption observed on game window
* [AMDVLK issue #236] Confusing implementation of VK_EXT_hdr_metadata
* GPU Profiler: per-draw SPM filenames collide and clobbering each other if the draws use the same shaders
You implement VK_EXT_hdr_metadata in a way where setting HDR metadata forces the internal swapchain color space to
HDMI_EOTF_SMPTE_ST2084
, completely ignoring the value ofpColorConfig->colorSpace
.This means that, effectively, passing HDR metadata puts the display into ST.2084 mode even when the colorSpace chosen for the swapchain is
COLOR_SPACE_SRGB_NONLINEAR_KHR
, a contradiction. As is, this implementation basically requires users hard-coding undocumented vendor-specific behavior, and leaves important questions unresolved (e.g. what primaries are in use).The correct way forward, I think, would be to expose support for
VK_EXT_swapchain_colorspace
, addVK_COLOR_SPACE_HDR10_ST2084_EXT
as a valid swapchain color space type, and set the HDMI EOTF depending on this color space.The text was updated successfully, but these errors were encountered: