[News] Vulkan Progress Report

[dark_sylinc]

https://www.ogre3d.org/2019/11/05/vulka ... ess-report

[hedphelym]

Exciting news! Thanks for all the hard work you do!

[SolarPortal]

yes, well done! looking forward to the end result

[xrgo]

yeeeees! Ogre on Oculus Quest =D

[longer]

This is an important and decisive news for mobile platform developers!

[Hotshot5000]

Hi dark_sylinc,

I have some time when the artist will work a bit more and me a bit less (I have to wait for him ) so I thought of going back to working on Ogre for the next few months (I know, I know, I said I will work on vulkan more than one year ago...).
I cloned the 2.2 git repo (I stayed on mercurial for the current game that I am working on) and saw there was vulkan branch. But the last update was on November 18th. Do you plan on continuing the implementation of vulkan support anytime soon? I might be able to help with this even though I have never used vulkan before (except tutorials and simple stuff...).

So, if you want, I can start understanding what you have done and try to continue, or you can tell me: I will work on this and you can focus on that submodule, give me some hints on what the priorities are etc...

I only have 2-3 hours per day when I can work on this (and some days I won't be able to work on ogre at all), but, even though progress will be slow, at least it will be faster than standing still .

[dark_sylinc]

I only have 2-3 hours per day when I can work on this (and some days I won't be able to work on ogre at all), but, even though progress will be slow, at least it will be faster than standing still .

Progress has been stalled, as I'm focusing on other stuff.

But help is always welcome! I'll have to take a look at what was pending again (there was a lot!) to get a better focus.
I also had a quick sample to test the triangle, as I was trying to get shaders working (IIRC that was a success), and then move on to buffers.

Ping me again if I forget.

[Hotshot5000]

Hit the first roadblock it seems. glslang is built today by Khronos group using Visual Studio 2013 (_MSC_VER == 1800) and I only have VS 2017 (with the VS 2015 toolset so minimum _MSC_VER == 1900).

I built glslang locally but for some reason I get lots of messages like the following when trying to link to the Ogre render system:

Code: Select all

glslangd.lib(ShaderLang.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1900' in OgreVulkanWin32Window.obj

Which is very strange since I didn't built it with 1800 since I don't have that compiler on my PC.

According to their documentation glslang should build fine using Visual Studio 2015 but they didn't test with VS 2017. I have raised a ticket with them, let's see how this goes. Looking through their code it seems they are limited to _MSC_VER == 1900.
It also seems to choose and older Windows SDK by default, that might be a cmake configuration problem. I have forced it to use the latest but no dice. I get the same linker errors with the msc ver mismatch.

Worst case scenario I will have to clone their repo and try to make a patch to get it working with at least _MSC_VER == 1900. Bleah....

[dark_sylinc]

I only tried Linux while I was developing (it didn't go very far as you have seen) and as you saw the SDK paths were hardcoded.
Thus I don't think I even tried to get a working window in Windows (i.e. swapchain management was for X11).

I too had to build from source, but the SDK they provide was already a copy of their Github repo IIRC, and the 'vulkansdk' script provided a way to build from source.

You can tell CMake which lib to build for via command line. If the same error still persist, then the problem is a more basic one... your VS is just looking for the .lib files in the wrong folder.

[Hotshot5000]

In the end I had to rebuild the whole google shaderc in order to make it work. Initially I downloaded the VulkanSDK provided by LunarG and tried to get glslang from Khronos Group to work. Only now I realized that shaderc was what I needed. Documentation could seriously be improved with Vulkan libs. I was looking for VulkanSDK repo instead of shaderc.

Now I have a compilable VulkanRenderSystem. Next step is getting Win32VulkanWindow working.

[Hotshot5000]

A little update. Win32 Vulkan window seems to be created properly. VkSurfaceKHR gets created, swapchain etc. Now I get a crash when setting up depth attachment in VulkanRenderPassDescriptor. I will investigate.

Just an update so that people see that I am still working on this. Progress is slow though as this is the first time I use Vulkan so there is a big learning curve.

[libolt]

This is great to hear. I'm about to port my game from Ogre 2.1 to 2.2 and will be using the GL3PLus renderer for the time being. I look forward to giving the Vulkan renderer a try once it is usable.

[Hotshot5000]

Small update:

I didn't realize that 2.2 has some new methods in OgreRenderSystem

Code: Select all

virtual void _descriptorSetTextureCreated( DescriptorSetTexture *newSet ) {}
        virtual void _descriptorSetTextureDestroyed( DescriptorSetTexture *set ) {}
        virtual void _descriptorSetTexture2Created( DescriptorSetTexture2 *newSet ) {}
        virtual void _descriptorSetTexture2Destroyed( DescriptorSetTexture2 *set ) {}
        virtual void _descriptorSetSamplerCreated( DescriptorSetSampler *newSet ) {}
        virtual void _descriptorSetSamplerDestroyed( DescriptorSetSampler *set ) {}
        virtual void _descriptorSetUavCreated( DescriptorSetUav *newSet ) {}
        virtual void _descriptorSetUavDestroyed( DescriptorSetUav *set ) {}

I was familiar with 2.1 which as far as I remember didn't have this (at least the version that I use in my game didn't) which means that I kind of wasted quite a bit of time trying to keep descriptor set info only in the vulkan render system so as not to have to modify OgreMain stuff.

Of course I was failing at this since the buffers must be matched with the descriptor sets higher in the chain and making this data only available in the specific vulkan render system was either impossible or involved lots of ugly hacks (trying to match created const buffers with gpu params bound in RenderSystem::bindGpuParameters() and doing vkUpdateDescriptorSets() there? Not sure this is possible...).

Anyway all is not lost since I got to familiarize myself with descriptor set layouts, descriptor pools and of course descriptor sets and how to update them which is needed anyways. But having something like DescriptorSetTexture2 and DescriptorSetSampler makes life liveable again.

My bad for not reviewing the differences between 2.1 and 2.2 better before starting with vulkan. Guess it's lesson learned then

[Hotshot5000]

But what do we have here?


This is the first frame of the Sample_CustomRenderable using the Vulkan render system and the only one usable. The next frame everything gets corrupted ))

Still, this is just the beginning. Need to work out how to reuse BufferViews etc. Right now I am creating one for every frame and leaking memory like crazy (no fences to get notified that the buffer view is no longer needed). Also offsets in dynamic buffers don't work yet... And for some reason the drawId buffer has data from the index buffer, no idea how that happened

Will keep you posted with further updates! One really unfortunate thing about vulkan is the lack of documentation. The Vulkan Programming Guide from Graham Sellers and John Kessenich is mostly just a reference manual. Progress would have happened much faster with better docs...

[dark_sylinc]

Yay!!!

I did not expect progress so fast!



Feel free to add a pull request and mark it as 'in progress'

Progress would have happened much faster with better docs...

If you've got questions, send me an email.