DragonJoker / Ashes

Drop-in replacement for Vulkan shared library, for older hardware compatibility
https://dragonjoker.github.io/Ashes/
MIT License
357 stars 19 forks source link

Can't use vkGetSwapchainImagesKHR with OpenGL #260

Closed LouisClt closed 2 years ago

LouisClt commented 2 years ago

Hello, I am trying to use Ashes in "drop in" replacement mode, on Windows. I built Ashes using vcpkg. I had a working Vulkan code which made use of these functions (which seems to be somewhat standard methods for vulkan):

Loading ashes-1.lib in lieue of vulkan library made link errors concerning these functions.

Trying to load them with the vkGetProcAdress method seems to work well when I use the Vulkan plugin. But when I try to use OpenGL plugin, the functions' pointers are all null.

Looking at the code of the Ashes library it seems that these methods might be correctly defined but not exported.

Is that the normal behaviour or did I do something wrong ?

Regards

DragonJoker commented 2 years ago

Hi So, I've tried, and I haven't encountered that issue, did you make sure you had ashesGlRenderer.dll in the same folder as ashes-1.dll ?

LouisClt commented 2 years ago

Hello,

Thanks for your answer.

Yes I did make sure that I had the ashesGlRenderer.dll in the same folder.

I managed to make my code work (there are still OpenGL errors (glBlitFramebuffer) but it is another issue I think) by adding this code:

#if VK_KHR_swapchain
            VkExtensionProperties{ VK_KHR_SWAPCHAIN_EXTENSION_NAME, VK_KHR_SWAPCHAIN_SPEC_VERSION },
#endif

in ash_opengl.cpp line 4608 (which activated the extension VK_KHR_swapchain, else the plugin returned that this extension was not activated and we could not do the vkGetInstanceProcAddr correctly)

For the static linking without vkGetInstanceProcAddr I had to add :

GlRenderer_API VkResult VKAPI_CALL vkGetSwapchainImagesKHR(
        VkDevice device,
        VkSwapchainKHR swapchain,
        uint32_t* pSwapchainImageCount,
        VkImage* pSwapchainImages)
    {
        return ashes::gl::vkGetSwapchainImagesKHR(device, swapchain, pSwapchainImageCount, pSwapchainImages);
    }

line 4750 of the same file (and the corresponding declaration in the hpp file).

What I do not understand is how it can work for you. Maybe the test you've done was from the library itself that does not care about the API that is exposed ?

DragonJoker commented 2 years ago

The idiomatic way for Ashes loading is using ICD mode (setting the environment var VK_ICD_FILENAMES to the appropriate json file), and if not, I strongly advise against static linking, which is a convenient but bad way of using Vulkan. Also, VK_KHR_swapchain being a device extension, its function pointers should be loaded using vkGetDeviceProcAddr (even though Vulkan loader may accept loading them through vkGetProcAddr or vkGetInstanceProcAddr, I don't allow it in Ashes' renderers).

LouisClt commented 2 years ago

My bad, with vkGetDeviceProcAddr, I have no more issues. I was not aware that the correct way for loading functions was dependant on the type of the extension, having only worked with Vulkan SDK. I will look into ICD. Thanks for your answers,