[News] Vulkan Progress Report

News, announcements and important global threads from the Ogre3D Team.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

[News] Vulkan Progress Report

Post by dark_sylinc »


hedphelym
Gremlin
Posts: 174
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 16
Contact:

Re: [News] Vulkan Progress Report

Post by hedphelym »

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

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 50
Contact:

Re: [News] Vulkan Progress Report

Post by SolarPortal »

yes, well done! looking forward to the end result :)
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 166

Re: [News] Vulkan Progress Report

Post by xrgo »

yeeeees! Ogre on Oculus Quest =D

longer
Kobold
Posts: 35
Joined: Tue Aug 19, 2014 10:46 am
x 3

Re: [News] Vulkan Progress Report

Post by longer »

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

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by 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 :D ) 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 :D .

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Hotshot5000 wrote:
Thu Feb 27, 2020 9:50 pm
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 :D .
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
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by 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....

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by 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
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by 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
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by 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
Greenskin
Posts: 112
Joined: Wed Jan 19, 2005 4:48 am
x 6

Re: [News] Vulkan Progress Report

Post by 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
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by 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
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

But what do we have here?
Image

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...

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Yay!!!

I did not expect progress so fast!

:D

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.

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

I was working on texture support for Vulkan render system and I was wondering if there is a more elegant solution for the following issue:

There looks like there is more than one way to set textures and samplers in the render system. For example when using the DebugFont (for rendering debug text in the CustomRenderable example) the texture gets loaded and data passed to GPU using the staging texture class. Then the _setTextures(DescriptorSetTexture*) to set the texture. And then _setSampler(DescriptorSetSampler*) to set the sampler.
But there also looks like there is the DescriptorSetTexture2* set of _descriptorSetTexture2Created() and _setTextures(DescritproSetTexture2).

The problem is that in Vulkan the VkImageView and the VkSampler must be matched inside the VkDescriptorImageInfo. I can make it so that VulkanRenderSystem holds a map of the textures and the samplers belonging to them so that in the _render() they are matched correctly before calling vkUpdateDescriptorSets (irrespective from which _setTextures() call the textures come) but I wanted to have a confirmation that I am on the correct road for this and there isn't a better way that is already supported by Ogre and that I am missing. Is there another structure that contains the textures with their correctly matched samplers that I can already use?

I will create the 'in progress' PR shortly.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Hi!

There are three ways to set a texture:
  • _setTexture: This was for legacy reasons. I ran out of time. It's just your typical D3D11-style set-one-texture-at-a-time table. The only one that's not Vulkan-friendly.
    I was wondering whether for Vulkan we'd have to remove this one and replace all of its uses with one of the other variants; or if we'd implement a "rolling" texture descriptor engine/emulator which is what some people did to port their D3D11-style engines to Vulkan
  • _setTextures( DescriptorSetTexture ): The default one. It's simpler to setup. This version assumes the view always matches the same format as the texture's original format. For example if the pixel format is PFG_RGBA8_UNORM_SRGB, then the default vkView to create is PFG_RGBA8_UNORM_SRGB.
    Also we can only bind textures through this version.
  • _setTextures( DescriptorSetTexture2 ): The advanced one. It's more complex to setup. This version allows binding both buffers and textures. It also allows reinterpreting formats (as long as the texture was created with Reinterpretable flag) for example if the original pixel format was PFG_RGBA8_UNORM, it can be reinterpreted to either PFG_RGBA8_UNORM or PFG_RGBA8_UNORM_SRGB
Basically don't worry about the DescriptorSetTexture vs DescriptorSetTexture2 variants, because the former one is just the same as the latter but assuming defaults.

EDIT:
Oh sorry: Reading comprehension problems. The problem comes from setTextures and setSamplers must be combined into one.
Well, that's not a problem. These calls are too low level (won't break anyone) and if you see our code we call addCommand<CbTextures> and addCommand<CbSamplers> always together.

Thus it's no big task to merge them together into _setTexturesAndSamplers(). If you go this route, I suggest you start this on a clean master branch so that you submit your PR to master (i.e. switch GL3+, D3D11 and Metal to use _setTexturesAndSamplers) thus we make this change ASAP before potential merge conflicts arise, independent of any Vulkan progress (i.e. don't delay this task until Vulkan is ready).

Btw I strongly recommend you use master branch. We have unit tests there now (see Scripts/UnitTesting/RunUnitTests.bat)

EDIT2:
Looking at the documentation, I believe (not 100% sure) you're allowed to set VK_NULL_HANDLE and update them separately.
Vulkan has three descriptor types:
  1. VK_DESCRIPTOR_TYPE_SAMPLER: Samplers (D3D11 style)
  2. VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE: Textures with no samplers (D3D11 style)
  3. VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER: Textures with samplers combined. (OpenGL style)
I believe Vulkan has a struct to ask for both fields when you're using VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER.

EDIT3:
Confirmed:
  • For VK_DESCRIPTOR_TYPE_SAMPLER, only the sampler member of each element of VkWriteDescriptorSet::pImageInfo is accessed.
  • For VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT, only the imageView and imageLayout members of each element of VkWriteDescriptorSet::pImageInfo are accessed.
  • For VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, all members of each element of VkWriteDescriptorSet::pImageInfo are accessed.
I never intended for us to use VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, thus there should be no need to combine _setTextures and _setSamplers into one.

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

Yes you are right. I was reading the https://vulkan-tutorial.com/Texture_map ... ge_sampler and got the impression that only VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER is valid.

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

dark_sylinc wrote:
Wed Jul 15, 2020 11:33 pm
I never intended for us to use VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, thus there should be no need to combine _setTextures and _setSamplers into one.
So you say we should not have combined images and samplers? I ask because I simply took the GLSL shaders from GL3Plus render system and put them in the Vulkan render system (they needed a few changes but I was hoping I can ultimately share the shaders between GL3Plus and Vulkan). Right now in GLSL I see uniforms like uniform sampler 2D textureMaps[] which I understand are combined image and samplers.

I have just discovered https://github.com/KhronosGroup/GLSL/bl ... n_glsl.txt

I was sure that vulkan just used the normal GLSL from OpenGL. So it looks like the shaders won't be shared with GL3Plus like a hoped.

In Vulkan GLSL it looks like you can have things like:

Code: Select all

#ifdef VULKAN
            layout(set = 1, binding = 0) uniform sampler s;
            layout(set = 1, binding = 1) uniform texture2D t;
            #if VULKAN > 100
                ...
            #endif
        #else
            layout(binding = 0) uniform sampler2D ts;
        #endif
One more thing that I have learned. Vulkan seems more and more versatile day by day :)

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Everything you said is correct.

Our GLSL code uses combined sampler and textures because OpenGL forces us to do so. D3D11 and Metal have it separate.

RSC_SEPARATE_SAMPLERS_FROM_TEXTURES is unset for OpenGL, it is set for D3D11 and Metal (and should be for Vulkan as well).

When RSC_SEPARATE_SAMPLERS_FROM_TEXTURES is present updateDescriptorSets in OgreHlmsTextureBaseClass.inl will account for this and generate samplers that don't repeat themselves.

Checkout our HLSL and Metal files to see how the samplers are declared independently from the textures. The rest of the code is in .any files which automatically handles samplers.

This is because CrossPlatformSettings_piece_all.glsl defines OGRE_Sample & co to ignore the sampler argument:

Code: Select all

#define OGRE_Sample( tex, sampler, uv ) texture( tex, uv )
while their CrossPlatformSettings_piece_all.hlsl and *.metal do use the sampler.

Obviously in Vulkan CrossPlatformSettings_piece_all.glsl should use an alternate macro to use that sampler just like in HLSL/Metal
One more thing that I have learned. Vulkan seems more and more versatile day by day :)
Imagine a teacher asking what a cake he's baking should have and he tries to please every kid in the class. "I want it to have lots of sugar with vanilla and chocolate" said one. "I want it to be very salty, and with fruits" said another.
So the teacher poured sugar, chocolate, salt and fruits; and many other things the rest of the kids asked.

That's what Vulkan is. Everyone agreed separate samplers was the future until a couple vendors complained their HW was slightly faster when using combined samplers. And that pretty much repeats throughout all of Vulkan.

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

Another thing that I am not sure I understand about vertex buffer attribute conversion is why

Code: Select all

in vec4 vertex;
in opengl behaves differently from vulkan.

For example, you have the POS_TEX_BINDING vertex buffer in OgreTextAreaOverlayElement which has a vec3 position followed by vec2 uv. These two are bound in the shader as

Code: Select all

in vec4 vertex; in vec2 uv;
and it seems to work fine when doing

Code: Select all

gl_Position = vertex * worldViewProj;
as if vec4 vertex would be a

Code: Select all

vec4(vertex, 1.0)
.

In vulkan the same shader results in the vertex containing the x y z vertex position and the .w is the 'u' from the uv which is next in the buffer struct.

Why is vec4 vertex auto expanding the vec3 vertex that is in the bound buffer input to vec4(vertex, 1.0)?

EDIT: According to https://stackoverflow.com/questions/189 ... c4-or-vec3 the expansion happens normally in GLSL. Maybe it's an extension thing as Vulkan GLSL has some differences from OpenGL GLSL.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Aww that's sad. Assuming position.w was default-init to 1.0 was a nice way of handling most data (which is float3) while also being compatible with custom vertex buffers who want to use a custom .w value.

OpenGL is decades old and was user friendly. Certain variables and values have sane defaults.
But that means the driver needs to check when a value is uninitialized and should use sane defaults.

e.g. OpenGL assumes uniform variables are default initialized to 0 if they're not set. In Vulkan it is invalid to not initialize uniform variables.

Vulkan mentality is "I know what I'm doing, you don't need to waste time on verifying my stuff" and the driver is like "OK then", thus any uninitialized or invalid value is not double check and will happily crash your app.

The only exception is that the driver should not allow a user space program to crash the OS (BSOD).
However I am playing an AAA Vulkan game and if I stay too long in the Main Menu, the entire system hangs spectacularly (Display gets turned off, sound gets stuck in the last ms being played, keyboard locks up, and not even Reset button works. I have to hold power down for 10 secs).

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

How do you think I should go forward? Right now I am thinking of just using vec3 and adapting the shaders so I can get the CustomRenderable sample working, but I don't know how many plugins/features need the vertex to be vec4 so I don't know how big the adaptation effort might be.

I could probably add some @property in the shader so that if you need it it's declared as

Code: Select all

in vec4 vertex;
instead of vec3. Is this a reasonable solution?

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4545
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 954
Contact:

Re: [News] Vulkan Progress Report

Post by dark_sylinc »

Yeah we're gonna have to use a property, set in Hlms::calculateHashForSemantic only for Vulkan, so that we use vec3 (and change the any file to manually construct float4( input.xyz, 1.0f ) ).

Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 209
Joined: Thu Oct 14, 2010 12:30 pm
x 48

Re: [News] Vulkan Progress Report

Post by Hotshot5000 »

Yep I tried vec3 and now I can see the text. The problem now is that I just realized that the whole viewport is flipped. The text is on the left and bottom side and upside down as is the cube. So the whole texture seems to be flipped. I remember there was something related to requiresTextureFlipping() or something like this in OpenGL...

EDIT: I think I found the answer: https://www.saschawillems.de/blog/2019/ ... -viewport/

EDIT2: Looks like it doesn't work as expected...
Image

I just reversed the y and height on the viewports:

Code: Select all

VkViewport vkVp[16];
for( size_t i = 0; i < numViewports; ++i )
{
        vkVp[i].x = mCurrentRenderViewport[i].getActualLeft();
        vkVp[i].y = mCurrentRenderViewport[i].getActualHeight();
        vkVp[i].width = mCurrentRenderViewport[i].getActualWidth();
        vkVp[i].height = -mCurrentRenderViewport[i].getActualHeight();
        vkVp[i].minDepth = 0;
         vkVp[i].maxDepth = 1;
}
vkCmdSetViewport( mDevice->mGraphicsQueue.mCurrentCmdBuffer, 0u, numViewports, vkVp );
EDIT3: Fixed it with:

Code: Select all

rasterState.frontFace = VK_FRONT_FACE_COUNTER_CLOCKWISE;
instead of the clockwise. Not sure why it works right now I am too tired to focus. I will think about this more in the morning.

EDIT4: It makes sense. If you invert Y coord then what used to be clockwise is now CCW :).

Post Reply