SharpVk-Samples
SharpVk-Samples copied to clipboard
FacticiusVir
Switch samples to use GLFW
Current sample projects use WinForms as the Surface host, which makes them dependent on Windows; GLFW is a cross-platform window library with explicit support for Vulkan Surfaces.
@sunkin351 Could you try the Test Harness project in the GLFW branch to see if it runs on Linux? I've tested on Win32 and it works okay for me. It'll need a 32-bit compile of libglfw.so which I don't have; you can change the project to an x64 build config and it should still work, or update the dllmap tag in App.config if you need to point to a different file.
I'm not sure what genius decided to name the vulkan library different on windows and linux, windows adds a "-1" to the end of the name before the file extension... which is irritating. Is there anything you can do about that at runtime?
Edit:
Also, since C# gives the feature of using [DllImport("vulkan")], I would advise using that instead of the complete library name and let the runtime choose.
I wonder if it will account for the "-1" in the windows name...
Mono supports DLL mapping - you can see an example here for my GLFW bindings: https://github.com/FacticiusVir/SharpVk/blob/Glfw/SharpVk/Test%20Harness/App.config
I'll add one to the repo, but in the meantime you can fix it directly in the build output by adding a SharpVk.dll.config file in the same format as the link, drop the startup element and update the dllmap line to be:
<dllmap os="linux" dll="vulkan-1.dll" target="vulkan.so"/>
(I'm assuming the Linux library is called vulkan.so)
libvulkan.so, but yea. I am changing a little code in the sample to match linux needs. (Xcb surface so far) Is it possible to compile once and have it run on multiple platform? (using dllmap and such?)
Btw, you wouldn't happen to know why vulkan is telling me I have two Graphics cards when I only have one, would you? (Nvidia GeForce GTX 750 Ti)
Is it the same name for both? If not, it might be picking up the on-chip GPU on some Intel CPUs.
Its the same name, type, and ID. Plus my mb doesnt support onboard video.
Odd, not sure about the multiple physical devices; also, I'm reworking the marshalling/interop layer to fix the CreateRenderPass issue now, but it looks like a lot of the unmanaged memory code simply isn't Mono-compatible so it'll take me a little while. For the XCB Surface change in the sample, is that just to include the correct extension name? If so, I can easily update the sample to detect the current platform's surface extension and load that, so it'll work cross-platform.
Its really funny, because that is the only function I have come across that creates a SigSegV. Everything else that isn't dependent on a render pass pretty much works from what I can tell. (Except for maybe all those warnings on device creation from the validation layers.)
I would hate to be a pest, but can you give me a timeframe to expect this done?
No worries, I've got some fixes in place that I'm testing, should have something to you this weekend.
Right, was having a nightmare reworking for PCL, so I've separated and tested the Mono fix on it's own, along with the NVX extension patches that appeared last week; I was able to replicate your original issue on Windows with Mono, and the latest commit to the GLFW branch seems to resolve it.
Note to self: if you're moving house of a weekend, remember to push your local git commits before the Internet is disconnected.
I am able to get past the part where it would previously crash at CreateRenderPass(). I will let you know if I encounter any more problems. Thank you for your hard work. Could this get merged into master where my projects can benefit?
Also, would you like to incorporate some glfw interop code in your library? It would definitely help.
WOW... The sample you made has a serious issue at least on Linux, I gave it free reign over my gpu and it lagged my entire system to hell, I almost couldn't move my mouse to close the window. I seemed to have solved this problem by using device.WaitIdle() just after the present call: presentQueue.Present() in Program.DrawFrame(). Otherwise, it runs well and no issues.
Interesting; possibly a different blocking behaviour on AcquireNextImage for Windows drivers, either way I'll add some additional synchronisation and get a merge up to master later, then flesh out the "proper" version.
Could you please add something to the official repo to give me the status/return code of Device.WaitForFences()? It would be very helpful for future synchronization.
Edit: I also cant seem to figure out dllmap, could you provide an example? ~~Edit2: There is also a definite crash for me when trying to allocate command buffers. Will send you a debug report shortly.~~ Scratch that, completely my fault. :)
Which dllmap isn't working for you? There should be one included in the SharpVk.Glfw library already.
App.config in the SharpVk project:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<dllmap os="linux" dll="vulkan-1.dll" target="libvulkan.so"/>
</configuration>
The dllmap configuration is now included in the master branch SharpVk project.
It should be compiled to SharpVk.dll.config, and that file should be in the folder with SharpVk.dll (along with SharpVk.Glfw.dll.config & Test Harness.exe.config)
Note that a "compiled" config file will have the same contents as the un-compiled, it just renames the file.
That's bizarre, having done some googling it seems Mono doesn't process app.configs for you at all; I'll see if there's a way to make the project builds cross-compatible.