Why does pickImageExtent require currentExtend.width to be UINT32_MAX

dxvkclosed

doitsujin/dxvk#2346 · opened 2021-10-25 by W4RH4WK · updated 2021-10-25 · 5 comments · github

WW4RH4WK 2021-10-25 github

Using DXVK-native here on a platform that is not Linux nor Windows, I stumbled across this check:

https://github.com/doitsujin/dxvk/blob/8912c7adb09d6c23b989a67567049df45029b1fa/src/vulkan/vulkan_presenter.cpp#L418-L419

I am not sure why it's there. In my case desired is 1920x1080, while currentExtent is 1280x720. maxImageExtent is >= 1920x1080 so there shouldn't be a problem. Yet, with the two lines there, the desired resolution is not picked.

Mmisyltoad 2021-10-25 github

currentExtent is the current width and height of the surface, or the special value (0xFFFFFFFF, 0xFFFFFFFF) indicating that the surface size will be determined by the extent of a swapchain targeting the surface.

Therefore you cannot use any size than currentExtent for your swapchain.

WW4RH4WK 2021-10-25 github

Ah, directly comes as a result of the spec, I see. Thank you.

WW4RH4WK 2021-10-25 github

Okay, it seems that you can, although the behavior is platform dependent:

The behavior is platform-dependent if the image extent does not match the surface’s currentExtent as returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR.
-- VkSwapchainCreateInfoKHR

Mmisyltoad 2021-10-25 github

Seems like that contradicts the currentExtent wording. :/

WW4RH4WK 2021-10-25 github

I think it's fine. Trying to be pedantic about it, the wording of currentExtent does not state that the width and height provided for swapchain (re)creation has to be equal to currentExtent unless it's (0xFFFFFFFF, 0xFFFFFFFF).

(0xFFFFFFFF, 0xFFFFFFFF) indicates that the surface size will be determined ...

This does not imply that the surface size can only be determined by the swapchain extent when currentExtent is (0xFFFFFFFF, 0xFFFFFFFF).

To me, it reads like it should be fine as long as your extent stays within minimum and maximum bounds. It's just that when deviating from currentExtent there might be platform specific quirks you have to look out for. In my case, the surface seems to just change its extent upon swapchain creation with a different size.

At least that's my take on it right now.

On my platform here, creating the swapchain with 1920x1080 despite the capabilities having currentExtent set to 1280x720 works as expected. Swapchain is created successfully with the desired size of 1920x1080. Also the device's output signal is 1920x1080.

As for the code, I think it's fine to leave the check in, in order not to trigger any unwanted, platform dependent behavior on accident. Should I add a comment about this, just in case it comes up again?

Nothing extracted yet.