Vulkan is Next-Gen OpenGL
I'm probably not doing myself any favours here by using MinGW-w64...
That being said, it's kind of irritating to require us to build your project using CMake (and download Python), but only support Visual Studio anyways. Downloading and installing that beast is a huge investment just to compile a single library.
EDIT: Oh man, am I glad I found out you can get the VC++ build tools without downloading the whole kit and caboodle.
EDIT 2: This is ridiculously frustrating. If I enable the debug layers, I get a segfault from vkResetFences, which I have not called explicitly.
Yes, the exit would always have happened after a pipeline flush. I think the issue ended up being that the image was still owned by the presentation engine rather than the application when I tried to destroy the swapchain, but it was hard to tell for sure because even completely unrelated things seemed to fix it, like creating an already-signaled fence at initialization and then waiting on it before termination, or just stepping through a debugger and putting more time between the last vkQueuePresentKHR and vkDestroySwapchainKHR.
If I've learned anything from my efforts today, it's that Vulkan development, especially if you're learning by mostly trial-and-error, is next to impossible if you can't use the validation layers. And with no existing knowledge base, it's trial-and-error to get the layers working in the first place...I have no idea if it's because I'm on Windows 7, or because I have AMD hardware, or because I use MinGW and not MSVC, or what.
Don't forget the validation layer and the loader are open source so you can step into their code if you build them and have an idea about what make them crash.
I don't think OS makes a difference. However compilers might, I don't know how good mingw and msvc compatibility is especially since the debug layers are using c++ (IIRC part of the abi differ, for instance exceptions).
I did recompile all the loader and layer libraries from source using the VS 2015 compiler, actually, and am using the debug versions. Though I guess since they're MSVC-generated a lot or all of the debugging information is only in the PDBs? Maybe I should give up on trying to use MinGW for this...
I was wondering how many AAA games would be using Vulkan. I heard that the Frostbite engine Mantle render would be converted to Vulkan, but it would only be used on platforms that don't support DirectX 12.
Aha! I finally managed to solve the problem!
I was reading this page more closely, and it turns out that the loader needs to be able to find the layers using registry keys that indicate the VkLayer_xxx.json manifests. I added them and it all works perfectly now, even through MinGW instead of VS2015!
I was wondering how many AAA games would be using Vulkan. I heard that the Frostbite engine Mantle render would be converted to Vulkan, but it would only be used on platforms that don't support DirectX 12.
It makes sense for engine to have a Vulkan spin since it makes Android port (almost) straight forward. There isn't the gl/gles "ambiguity" anymore and the render pass concept makes things like gbuffer achievable on tiled architecture while bringing some memory bandwidth saving on desktop (thus it makes sense to invest in them even if you don't target mobile at first)
I remember XCom being ported to ios and still keeping all the mechanics and gfx complexity and I think Vulkan may help with such dev.
It looks like although the Mali T880 and the Adreno 530 are marketed as Vulkan compatible, their drivers seem far from being working :
http://vulkan.gpuinfo.org/displayreport.php?id=128
http://vulkan.gpuinfo.org/displayreport.php?id=133
The Mali doesn't expose swapchain extension, no MSAA. And the grid max size for compute workload is 0...
Apparently both GPU support DX11 feature level but the Tessalation/Geometry Shader stage are not exposed.
I wonder how they got UE4 running on Galaxy S7 device. Or maybe they keep a more formal Vulkan announcement for Android N.
