Can anyone confirm the hooks will not work when using vulkan + amd card?

[tuple789]

I just noticed that users seems to have freeze when using amd cards, can anyone else confirm this or found a solution, i'm still investigating

[lukas0x1]

The Vulkan hooks have a bunch of issues since they were implemented poorly. The most problematic are syncing issues due to semaphores not being waited on correctly. I have fixed all of the issues by making it into a Vulkan layer and re-implementing a large chunk of it in my mod loader: https://github.com/lukas0x1/sml-pc/blob/main/src/layer.cpp.

I might push changes to this repo, although I'm not certain whether the developer would be willing to accommodate the changes into a layer. He doesn't seem to have any contact info linked, so I'm not able to reach him.

Theoretically most of the issues can be solved without making it into a Vulkan layer, but unfortunately intercepting vkAcquireNextImageKhr is unreliable and vkCreateDevice can't be hooked.

Feel free to contact me on discord: lukas0x1, if you have any further questions. And just in case the developer sees this, hit me up if you're still interested in improving this project.

[tuple789]

Just sent you an invite on discord lukas0x1, just have a few quesions if you don't mind

[lukas0x1]

sure thing

[belazr]

Just gonna chime in here...
I have found two issues with the Vulkan hook:
Like @lukas0x1 said there is an issue with the semaphores of vkQueueSubmit.

            VkSubmitInfo info = { };
            info.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
            info.commandBufferCount = 1;
            info.pCommandBuffers = &fd->CommandBuffer;

            info.pWaitDstStageMask = stages_wait.data( );
            info.waitSemaphoreCount = waitSemaphoresCount;
            info.pWaitSemaphores = pPresentInfo->pWaitSemaphores;

            info.signalSemaphoreCount = 1;
            info.pSignalSemaphores = &fsd->ImageAcquiredSemaphore;

The queue waits for the wait semaphores of vkQueuePresentKHR pPresentInfo->pWaitSemaphores but doesn't signal them again, so the original call of vkQueuePresentKHR just gets stuck on waiting for its original wait semaphores.

I have fixed this by just setting the signal semaphores of vkQueueSubmit to the wait semaphores. This way it first waits then executes its bit and then signals them so vkQueuePresentKHR can do its part when the hook command buffer was executed.

            VkSubmitInfo info = { };
            info.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
            info.commandBufferCount = 1;
            info.pCommandBuffers = &fd->CommandBuffer;

            info.pWaitDstStageMask = stages_wait.data( );
            info.waitSemaphoreCount = waitSemaphoresCount;
            info.pWaitSemaphores = pPresentInfo->pWaitSemaphores;

            info.signalSemaphoreCount = waitSemaphoresCount;
            info.pSignalSemaphores = pPresentInfo->pWaitSemaphores;

I think there is really no need for the ImageAcquiredSemaphore and RenderCompleteSemaphore in the hook. They are only necessary for a stand alone ImGui application.

The second issue is that the dimensions of the frame buffer are not set at all. Strangely for me it still worked on NVIDIA cards but not on AMD cards.
I have fixed this by calling GetClientRect if g_ImageExtent is still 0 and then setting the correct width and height in the VkFramebufferCreateInfo.

static void RenderImGui_Vulkan(VkQueue queue, const VkPresentInfoKHR* pPresentInfo) {
    if (!g_Device || H::bShuttingDown)
        return;

    if (g_ImageExtent.width == 0 || g_ImageExtent.height == 0) {
        // We don't know the window size the first time so we just query the window handle.
        RECT rect{};
        GetClientRect(g_Hwnd, &rect);

        g_ImageExtent.width = rect.right - rect.left;
        g_ImageExtent.height = rect.bottom - rect.top;
    }

    VkQueue graphicQueue = VK_NULL_HANDLE;
    const bool queueSupportsGraphic = DoesQueueSupportGraphic(queue, &graphicQueue);

    Menu::InitializeContext(g_Hwnd);

    for (uint32_t i = 0; i < pPresentInfo->swapchainCount; ++i) {
...

and

        VkFramebufferCreateInfo info = { };
        info.sType = VK_STRUCTURE_TYPE_FRAMEBUFFER_CREATE_INFO;
        info.renderPass = g_RenderPass;
        info.attachmentCount = 1;
        info.pAttachments = attachment;
        info.width = g_ImageExtent.width;
        info.height = g_ImageExtent.height;
        info.layers = 1;

This still has issues since you have to recreate the framebuffers when the render resolution changes but I did draw for me on injecting the DLL.

I have addressed this and other issues in my repository where I wrote everything from scratch and without ImGui:

https://github.com/belazr/EasyWinHax

Hope this helps!

[SteamKaibz]

@belazr This is great thanks for sharing !
I implemented your changes in my mods and i'm waiting for user feedback to confirm it works for them and i'll post here when i get feedback:
mod: https://www.nexusmods.com/doometernal/mods/1255 code: https://github.com/SteamKaibz/DE_AdvancedOptionsModPublic
mod: https://www.nexusmods.com/wolfenstein2thenewcolossus/mods/5 code: https://github.com/SteamKaibz/NewColussus_Qols_Mod

Edit: i can confirm that at least one user has confirmed the wolfenstein mod using your changes now works!
@belazr do you have an idea if using imgui with games that use present from compute will always have a huge performance cost (as it the case for my mods) or if it is somehow solvable?

[belazr]

That's great news @SteamKaibz , thanks for letting me know!
I can't say anything about the performance issues but I would be happy to look into it. Maybe I can figure something out.
Do you have the issue with Doom Eternal?
Also, do you have issues with changing the resolution while the mod is running? If so, I could try to fix that and open a PR on your repos.

[SteamKaibz]

@belazr I do have the performance issue with Doom Eternal when imgui is enabled (as user can choose to not use imgui features in the mod settings json file), however it's very subtle but i have more and more users reporting this issue, but, as i just released a new mod version with your changes, may be it fixed those, but the problem is it's not a consistent performance drop, it's really weird.
I know, the day where this game was released the dev said on twitter that users should disable steam overlay as this would degrade performance (steam has since released an update to fix that) so i wonder if, to this day imgui and its implementation in UniversalHookX is the issue causing the perf loss.
It would be absolutely awesome if you could figure something out and don't hesitate to contact me if you have any question or need feedback, testing, or anything else, i'm here.
About changing resolution while in game, i was able to change game resolution with the mod running and i had not crash/freeze, which suprised me as you mentioned that there could/should be issues.

[belazr]

@SteamKaibz
I did a bit of testing on Doom Eternal and nothing stood out so far. I can only test on AMD with the fix at the moment though.
I'll look into NVIDIA without the fix when I have the time. I'll just open an Issue on your repo to not spam this thread.
When changing resolution I wasn't testing properly and overlooked the CleanupRenderTarget() in hkCreateSwapchainKHR, so that's on me. Works fine for me as well after all.

[SteamKaibz]

@belazr Thank you so much for doing this! I'll talk to you there.