I’m still in the process of porting an OpenGL engine to Vulkan and there are some functionalities where I have still problems.
On EGL, there is a function eglChooseConfig that allows me to check whether a, for example, window surface could be created with a certain framebuffer combination (Color etc.) even before a window has been created.
Is there such a function in Vulkan? Might it be part of the window api?
Regards
Edit: Could it be that the list of available surface formats is defined per EGLDisplay on OpenGL but per VkSurface on Vulkan?
In Vulkan, the display engine does not care about things like depth buffers. The only thing the display engine provides are a surface, which produces a user-selected number of swapchain images, which have one of the formats the display engine allows.
Given a physical device that provides presentation capabilities and a surface to it, you can query information about the nature of swapchain images via vkGetPhysicalDeviceSurfaceCapabilitiesKHR and vkGetPhysicalDeviceSurfaceFormatsKHR.
Vulkan, being a low-level, explicit API, has no functions that just pick defaults. You must ask the implementation what it requires, and you have to adjust what you ask for to meet those requirements.
Vulkan doesn’t have the concept of a “display” in the way that you mean. A Vulkan implementation can provide the VK_KHR_display extension, but this is explicitly for rendering to a display. That is, instead of having a swapchain, you just shove a user-created image to the display itself. But this means the whole display; you’re not rendering to just a window. That is the purview of the surface, not the display.
The properties of a swapchain image are ultimately based on the surface. What you must provide in order to create a surface is platform-specific, though pretty much all of them either directly require a window or require an object whose creation itself requires a window.
The idea is that you don’t really need to query this kind of thing unless you already have a window that you want to draw to. It might be handy in terms of code organization, but it isn’t strictly necessary.
Ok, let me rephrase this: Vulkan needs a window (in order to get a VkSurface) to retrieve the surface formats while EGL apparently doesn’t need one.
Why is that so and can one emulate eglChooseConfigs behaviour with Vulkan? That means, querying surface format availability for a certain surface type without creating a window?
In OpenGL the framebuffer format that I receive from eglChooseConfig is usually RGB 565. However, in Vulkan there are to formats I have to respect: The one of the swapchain ( which apparently on my system is restricted to VK_FORMAT_B8G8R8A8_UNORM and one other) and the one of the attachments. Currently the color attachment uses the same format as for the swapchain images.
no 565 format has VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT set.
So, home comes it that in OpenGL, rgb 565 is regarded as most widespread available framebuffer format but in Vulkan it cannot be used as either swapchain or color attachment format?
No such format is required to have that feature. But an implementation can allow it. That table is only for what Vulkan guarantees implementations must provide.
It isn’t. It’s simply one that eglChooseColor picked for you based on whatever it’s doing.
Ok, last question: Calling eglCreateWindowSurface with a certain color format in EGLConfig is equivalent to using the same format for swapchain and color attachment, right?
I don’t know all that much about EGL, but Vulkan is designed to be low-level. The fact that the two APIs on the same hardware expose different sets of formats suggests one of two things: 1) the Vulkan implementation isn’t bothering to expose all of the surface formats the hardware can handle, or 2) many of the formats that EGL provides have some overhead associated with their use (the overhead may not be terribly large, but it doesn’t directly map to the monitor’s format).
Personally, I would trust the Vulkan implementation to be more likely bound by hardware requirements than the EGL one. Especially if EGL’s giving you surface formats that are 16-bit.
Ok, so I replaced 565 by 888. eglChooseConfig has no problem with it but VK_FORMAT_B8G8R8_UNORM or VK_FORMAT_R8G8B8_UNORM has no framebuffer attachment bit for it. Only RGBA will work with both.