search

DUOLabs333 / vulkan-stream

A Vulkan driver to stream commands over TCP
10 stars 1 forks source link

Vulkan applications are crashing with Invalid instance error #7

Closed DragonSWDev closed 1 month ago

DragonSWDev commented 1 month ago

Vulkan applications are crashing with following error:

ERROR: vkCreateXcbSurfaceKHR: Invalid instance [VUID-vkCreateXcbSurfaceKHR-instance-parameter]
Aborted (core dumped)

Machine: Mac mini M2 Host OS: macOS Sequoia 15.0 Guest OS: Fedora 41 KDE

DUOLabs333 commented 1 month ago

What application is this? Have you tried getting the loader properly without LD_PRELOAD?

DragonSWDev commented 1 month ago

@DragonSWDev This is vulkaninfo, same error on vkcube. I didn't try without LD_PRELOAD as it doesn't work for me and fails with undefined symbol.

DUOLabs333 commented 1 month ago

Hmmm, weird --- I just tried it locally, and it works fine. Did you make sure that CONN_ADDRESS and CONN_PORT point to an address that the host can bind on and the guest and connect to?

DragonSWDev commented 1 month ago

Wasn't that STREAM_ADDRESS and STREAM_PORT? I believe connection is established as I'm getting logs on both server and the client when I start Vulkan application on client.

DUOLabs333 commented 1 month ago

No, I changed the environment variables that it uses. What logs are you seeing on the host side?

DUOLabs333 commented 1 month ago

I updated the README with the proper environment variables.

DUOLabs333 commented 1 month ago

Are you still having this problem?

DUOLabs333 commented 1 month ago

I'll close this now. Please feel free to open a new issue if you are still facing this problem.

DragonSWDev commented 1 month ago

@DUOLabs333 First of all sorry for no answer, I was busy with other things. I can confirm that with fresh build and proper environmental variables it seems to work fine. I could run vulkaninfo and vkcube without issues.

By the way current code does not compile due to syntax error. In CmdBatch.cpp file on line 46 there is a call to the function called clearBatch but this function is called clearCmdBatch.

Also there is still issue with locating Vulkan lib on macOS and Linux so using DYLD_LIBRARY_PATH on macOS and LD_PRELOAD on Linux is still needed. Perhaps adding a note to the readme about this isn't a bad idea?

DUOLabs333 commented 1 month ago

In CmdBatch.cpp file on line 46 there is a call to the function called clearBatch but this function is called clearCmdBatch.

Yeah, I missed that in my renaming --- I have the fix locally, but I'm testing a fix for a game before I push it.

Also there is still issue with locating Vulkan lib on macOS

Are you saying that setting VULKAN_SDK isn't enough?

LD_PRELOAD on Linux is still needed

This shouldn't be needed, so I want to narrow down the cause of the error first. Can you give me ldd /usr/bin/vulkaninfo?

DragonSWDev commented 1 month ago

Are you saying that setting VULKAN_SDK isn't enough?

I didn't know about it, I recompiled vulkan_stream again with this variable and it seems to work fine after build. The only thing is that this variable name is a bit misleading. It suggest that it should be pointed to the Vulkan SDK install directory but instead it should be pointed into directory where libvulkan.1.dylib is located (which is located in SDK_install_dir/macOS/lib).

Perhaps it should be mentioned in readme.

This shouldn't be needed

And it seems it's not. I just tried it again and it works without it. Sorry for the confusion.

So it seems that it works fine without any workarounds. Thank you for your work.

PS: Is there an option to disable console log?

DUOLabs333 commented 1 month ago

Is there an option to disable console log?

What logs? There may be some left over from my last impromptu debugging session, but they should be gone by the next time I push.

DUOLabs333 commented 1 month ago

SDK_install_dir/macOS/lib

Yeah, that's why I asked you for the absolute path of the loader, so I know what to set the path to in the Buildfile. It's already fixed locally.

DragonSWDev commented 1 month ago

What logs? There may be some left over from my last impromptu debugging session, but they should be gone by the next time I push.

Those "Object serialized" kind of logs that are printed in both server and client side when Vulkan application is running. They can obscure application log in some cases.

Yeah, that's why I asked you for the absolute path of the loader, so I know what to set the path to in my program. It's already fixed locally.

Sorry about that again.

Also side note - is Windows version planned? With DXVK that could make GPU acceleration possible to some extent for Windows guest.

DUOLabs333 commented 1 month ago

Those "Object serialized" kind of logs that are printed in both server and client side when Vulkan application is running.

Huh, that shouldn't happen, since build.sh compiles with DEBUG=0. I'll take a look.

Also side note - is Windows version planned?

I'm not opposed to it, but I can't test it locally (a bare install of Windows 10 is ~30 GB, which is space I don't have). However, even if I was to officially support it, it would only be on the Vulkan side --- combining it with DXVK is up to the user (though I'm not opposed to putting instructions on how to do that in the README).

DUOLabs333 commented 1 month ago

Oh sorry, it turns out that DEBUG is by default turned on. To fix this, clean everything, and compile with DEBUG=0 build.sh.

DragonSWDev commented 1 month ago

Oh sorry, it turns out that DEBUG is by default turned on. To fix this, clean everything, and compile with DEBUG=0 build.sh.

Oh yeah, I didn't build it with DEBUG=0, that makes sense.

Perhaps if I manage to find some free time I can try porting it to Windows if I'll figure out how build system works. Older versions of DXVK (before version 2.0 which requires Vulkan 1.3) are working on MoltenVK with some modifications so that might be interesting thing to do. I'm not promising anything tho, I'm not very experienced with Vulkan and porting UNIX things to Windows.