[2.3] Vulkan Progress

[al2950]

I basically maintained the RSC_EXPLICIT_API path blind. When I started writing it, Vulkan specs was a draft and I didn't understand barriers too well. But turns out it works quite closely to how Vulkan actually works.

That must be a good feeling!

Progress here is really impressive, thank you to both of you for pushing this forward.

[Hotshot5000]

Appreciated!

@dark_sylinc: I am looking into moving to HLSL and I encountered an issue with the locations of data in const buffers.

Code: Select all

struct VS_INPUT
{
	float4 vertex : POSITION;
	float3 normal : NORMAL;
	uint drawId : DRAWID;
	
};

According to SpvReflectInterfaceVariable it looks like the locations for these 3 are 0, 1, 2. Which means that if there is some texture defined before the drawId the location for drawId would be 3. In GLSL you can force the location to be 15 but here it seems to be variable. Is there a way to force locations like in GLSL?

Looking over at the D3D11 render system it looks like it's just a static_cast<D3D11VaoManager*>(mVaoManager)->bindDrawId( usedSlots ); where it does ++usedSlots for the previous slots in order to determine which slot is the correct one for drawId (since it's always the last one)

[dark_sylinc]

Yeah D3D11 manages the bindings dynamically by reading the shader.

But I our Vulkan RenderSystem assumes these slots in multiple places (??? do we? Now I can't find it. Perhaps I'm wrong and we only assume drawId is at 15)

Also looking at SaschaWillems's samples it seems it's possible to select a different slot with an extension to the syntax.

[Hotshot5000]

Btw what merge tool do you recommend? I've been using KDiff3 for years but I got sick of it and recently moved to the trial version of semantic merge. I would like something that isn't just a dumb text merger but actually understands C++ and a friend recommended semantic merge. It cut down my merge time drastically because of it not being just a text merge but when it gets it wrong and thinks it understands when it actually doesn't bad things happen. I don't know if I should pay for it after the trial is over ($56 per year subscription) or if there is something similar/better cheaper/free.

[dark_sylinc]

Everyone has their own personal preference. I've been extremely comfortable with SourceGear DiffMerge for years.

[dark_sylinc]

After porting a few necessary shaders and fixing multiple bugs in VulkanRenderPassDescriptor, point shadows are working again!

StaticShadowMaps.jpg

[Zonder]

Btw what merge tool do you recommend? I've been using KDiff3 for years but I got sick of it and recently moved to the trial version of semantic merge. I would like something that isn't just a dumb text merger but actually understands C++ and a friend recommended semantic merge. It cut down my merge time drastically because of it not being just a text merge but when it gets it wrong and thinks it understands when it actually doesn't bad things happen. I don't know if I should pay for it after the trial is over ($56 per year subscription) or if there is something similar/better cheaper/free.

I'd report the problems to them and haggle an extended trial hehe

[SolarPortal]

good job guys!!! keep it up!

[Hotshot5000]

CustomRenderable sample now working under HLSL. Here is the commit. Also check the previous one as it ties into this commit.

I could have created a VulkanProgram base class from which VulkanGLSLProgram and VulkanHLSLProgram derive but I don't see the differences to be that big. So I just added some if( HLSL ) elses in code for specific HLSL stuff.

I am not sure that I got the type mapping right between the buffer types:

Code: Select all

static const char c_bufferTypes[] = "PBTtsuU";
    static const char c_HLSLBufferTypesMap[] = "ccttsuu";

One bad/ugly thing is that you can't set the drawId buffer in VulkanRenderSystem::executeRenderPassDescriptorDelayedActions() as the location depends on the shader. If I have some time I will investigate the vulkan extensions for HLSL that add a way to specify location in VS_INPUT struct.

What other samples should I test next? The pose sample, the PBSMaterial sample? I know not all of them work.

The next step after HLSL is fine would be to look into the Vulkan rendering subsystem setup since the initialization window is empty. Maybe I can add the settings to be similar to other RSs.

[dark_sylinc]

CustomRenderable sample now working under HLSL. Here is the commit. Also check the previous one as it ties into this commit.

OMG you did what!?

That's awesome.

To be honest I wasn't looking into having the Hlms Pbs use both HLSL and GLSL with Vulkan since that's double maintenance.

My main area of interest is having postprocessing/low level materials with HLSL.

I could have created a VulkanProgram base class from which VulkanGLSLProgram and VulkanHLSLProgram derive but I don't see the differences to be that big. So I just added some if( HLSL ) elses in code for specific HLSL stuff.

I was wondering the same thing, I agree at least for now (I'm not fully informed on the differences).

I am not sure that I got the type mapping right between the buffer types:

Code: Select all

static const char c_bufferTypes[] = "PBTtsuU";
    static const char c_HLSLBufferTypesMap[] = "ccttsuu";

I think not all HLSL shader binding combinations can map to our root layout perfectly, but that should work. However I think 'c' should be 'b'

One bad/ugly thing is that you can't set the drawId buffer in VulkanRenderSystem::executeRenderPassDescriptorDelayedActions() as the location depends on the shader. If I have some time I will investigate the vulkan extensions for HLSL that add a way to specify location in VS_INPUT struct.

It's not thaaaaaat bad though (we don't switch often).

But like I said I was thinking of using HLSL more for low level materials (which don't use drawid) than Hlms.

The next step after HLSL is fine would be to look into the Vulkan rendering subsystem setup since the initialization window is empty. Maybe I can add the settings to be similar to other RSs.

I agree.

I'll have to analyze your commits and cherry pick them. I was waiting for your HLSL commit so I could start porting more shader stuff (I found a way to port OpenGL postprocessing shaders, but I think using HLSL is the path of least resistance)

[dark_sylinc]

OK I'm taking a look at the HLSL stuff (which is already integrated).

There's a warning I missed (and you too! haha) in glslang:

An HLSL front-end for translation of an approximation of HLSL to glslang's AST form.

Status: Partially complete. Semantics are not reference quality and input is not validated. This is in contrast to the DXC project, which receives a much larger investment and attempts to have definitive/reference-level semantics.

Ouch. That means we should not use it with Hlms. No big deal. I wasn't planning to


DirectXShaderCompiler sounds more stable/robust, but I'm worried its Linux supports may become a problem when trying to support Android.

My goal is to attempt to use HLSL for low level materials, since existing shaders should map well to Vulkan without any major modification (could even theoretically work out of the box).

So far it seems glslang's HLSL support is close to that goal. This vertex shader (meant for D3D11) compiles out of the box on Vulkan too:

Code: Select all

struct VS_INPUT
{
	float4 vertex	: POSITION;
	float2 uv0		: TEXCOORD0;
};

struct PS_INPUT
{
	float2 uv0			: TEXCOORD0;
	float4 gl_Position	: SV_Position;
};
uniform matrix worldViewProj;

PS_INPUT main
(
	VS_INPUT input
)
{
	PS_INPUT outVs;

	outVs.gl_Position	= mul( worldViewProj, input.vertex ).xyzw;
	outVs.uv0			= input.uv0;

	return outVs;
}

However if I write:

Code: Select all

PS_INPUT main
(
	VS_INPUT input,
	uniform matrix worldViewProj; // Uniform is here
)
{
	// ...
}

The wrong shader is compiled (SPIRV expects worldViewProj to be a vertex location, not a uniform). I can live with that.

So far my current problem is that this shader:

Code: Select all

struct VS_INPUT
{
	float4 vertex	: POSITION;
	float2 uv0		: TEXCOORD0;
};

struct PS_INPUT
{
	float2 uv0			: TEXCOORD0;
	float4 gl_Position	: SV_Position;
};

uniform matrix worldViewProj;
uniform float4 anotherVal;

PS_INPUT main
(
	VS_INPUT input
)
{
	PS_INPUT outVs;

	outVs.gl_Position	= mul( worldViewProj, input.vertex ).xyzw;
	outVs.uv0			= input.uv0;

	return outVs;
}

Doesn't show up because the first row of worldViewProj is all zeroes. I'm still researching why is that.
Update: Happens with GLSL too. Must be probably a bug in buildConstantDefinitions
Update 2: Fixed

One bad/ugly thing is that you can't set the drawId buffer in VulkanRenderSystem::executeRenderPassDescriptorDelayedActions() as the location depends on the shader.

Don't worry. DrawID is mostly an Hlms thing. And if users want to use it, they can use GLSL

What other samples should I test next? The pose sample, the PBSMaterial sample? I know not all of them work.

You can abort that

[Hotshot5000]

Ok then so I will move to writing the Vulkan Rendering Subsystem Setup. See if I can get it working with options like other render systems.

Regarding HLSL support: I understand that Vulkan 1.2 has full support for HLSL. Right now if I remember correctly we are using Vulkan 1.1. Maybe an SDK update would make things work?

HLSL first class vulkan shading language

EDIT: Looking at it it seems that glslang doesn't support HLSL properly. Why the hell did they advertise it as such? I didn't even look at "Status: Partially complete." based on that blog post that HLSL is production ready on Vulkan... Using the same standards we can say that Ogre Vulkan is production ready ))

[dark_sylinc]

HLSL first class vulkan shading language

EDIT: Looking at it it seems that glslang doesn't support HLSL properly. Why the hell did they advertise it as such? I didn't even look at "Status: Partially complete." based on that blog post that HLSL is production ready on Vulkan...

Because they meant with DXC, aka Microsoft's compiler. I think they added some stuff in Vulkan to avoid workarounds or expensive code rewrites in DXC in order to support its output (i.e. if you can't fix the compiler, fix the assembly syntax)

Like I said my worry about DXC is getting it to work on Android. Also Vulkan 1.2 support doesn't seem promising either for phones. I'm trying to stick to the lowest possible version unless necessary because many phones simply don't receive driver updates (that's also going to be a bug fest, but one battle at a time).

[Hotshot5000]

Agreed. If you remember when I tried writing the GLES3 render system a couple of years ago I hit some awful driver bugs that I simply abandoned it. I reported the bug to Qualcomm and they said they solved it.... about a year later. With that kind of support and because I can't just go out and buy all the Android smartphones out on the market and test on each of them I gave up. The Android situation is embarrassing.

[dark_sylinc]

Agreed. If you remember when I tried writing the GLES3 render system a couple of years ago I hit some awful driver bugs that I simply abandoned it. I reported the bug to Qualcomm and they said they solved it.... about a year later. With that kind of support and because I can't just go out and buy all the Android smartphones out on the market and test on each of them I gave up. The Android situation is embarrassing.

Indeed. Vulkan is also in an embarrassing state, but it is in a tremendously much better state than GLES3 (also GPU driver updates via app store are coming, hopefully in half a decade we will stop worrying about this).

Also I came here to say that: Arggghhh!!! I now know why you set VK 1.1 with HLSL. Pixel Shaders generate a "OriginLowerLeft" we don't care but that triggers an error. Grrrrrrr.

That's it. I'll continue with porting GLSL shaders to be cross GL/Vulkan, which is known to work well and is stable.

[Hotshot5000]

So no more HLSL?

I didn't set Vulkan to 1.1 when moving to HLSL. I did that before in order to have the flip the viewport texture like so.

I had the same "OriginLowerLeft" issue but I thought I solved it with the

if( mShaderSyntax == HLSL )
{
int ClientInputSemanticsVersion = 110; // maps to, say, #define VULKAN 100
glslang::EShTargetClientVersion VulkanClientVersion = glslang::EShTargetVulkan_1_1;
glslang::EShTargetLanguageVersion TargetVersion = glslang::EShTargetSpv_1_1;
messages = ( EShMessages )( EShMsgDefault | EShMsgSpvRules | EShMsgReadHlsl );
shader.setEnvInput( glslang::EShSourceHlsl, stage, glslang::EShClientVulkan, 110 );
shader.setEnvClient( glslang::EShClientVulkan, VulkanClientVersion );
shader.setEnvTarget( glslang::EShTargetSpv, TargetVersion );
shader.setEntryPoint( "main" );
}

in VulkanProgram::compile().
I didn't realize that that forced us into 1.1 version of Vulkan I thought it would work even on 1.0 if you adjust the values.

Anyway, I think they should work on documentation. Very poor right now. Blogs and stackoverflow and reading headers. I had to experiment quite a bit to get over the "OriginLowerLeft" issue. Why is that not written clearly anywhere? I think that right now better docs would do the most good.

[dark_sylinc]

So no more HLSL?

Not for the time being. It seems that it is either a rabbit hole or can't fit the purpose:

1. Works everywhere
2. Simplifies porting thanks to HLSL shader reuse

I feel like HLSL will be very handy for users currently using D3D11 and want to port to Vulkan (since Desktop has stable bleeding edge Vulkan support). However if they want Android support at some point they'll likely have to port their shaders to Vulkan's GLSL variant.

I was hoping HLSL shaders would work for all of us (Windows, Linux, Android), but doesn't seem like that's possible

[Hotshot5000]

Maybe not all hope is lost: Vulkan shader compilers on Android and shaderc ? On desktop use the current method and for Android use shaderc?

[dark_sylinc]

What's the difference? It's just a different glsl compiler. All I right?
I'm not sure what's your point?

Cheers

[Hotshot5000]

glslc accepts both GLSL/HLSL source and SPIR-V assembly files as inputs.

The name is misleading.

[rujialiu]

Maybe not all hope is lost: Vulkan shader compilers on Android and shaderc ? On desktop use the current method and for Android use shaderc?

I think I have used shaderc (the version shipped with the vulkan SDK 1.5 year ago) to compile HLMS generated hlsl shader to compare the compilation speed with DX11's fxc. I don't think I had any compilation error though I have no way to run it so I don't know whether shaderc's hlsl compiler is really usable.

BTW: Oh my god your and dark_sylinc made such a huge progress on Vulkan support recently. I can't believe it!!!

[dark_sylinc]

glslc accepts both GLSL/HLSL source and SPIR-V assembly files as inputs.

Oh! I completely missed that! It's a matter of playing with it then (meanwhile I'm continuing the approach of porting our GLSL shaders. I'm done wasting time chasing alternatives; if we get HLSL working it is nonetheless useful for other users who are already targetting D3D11).

Btw I created a new temporary branch. It doesn't even compile. I'm refactoring the barrier system now that I have more experience with it and located the problems with the current approach.

The code is easier to understand too. Just compare the old bodies of _placeBarriersAndEmulateUavExecution vs the new bodies of _analyzeBarriers. The former was very verbose and hard to understand what it was doing, the latter is much shorter and straight to the point.

It should fix some of the currently broken samples, avoid some unnecessarily expensive barriers, and it will pave the way for adding Compute Shaders.

Once I'm done I will squash the commits and push it to the main vulkan one. I created the temporary branch because it was getting too big and I'm always paranoid of losing data

[Hotshot5000]

Small update: I have the initialization window working and populated but I am still working on making the FSAA parameter working. I get a crash in VulkanRenderPassDescriptor::setupColourAttachment() something related to textureResolves and mMsaaFramebufferName being NULL. I need to investigate but I think I will be done soonish.

[dark_sylinc]

Getting MSAA to work will require additional work since we're not creating the auto resolve buffers.

[dark_sylinc]

Btw after a lot of work refactoring the barriers, DynamicCubemaps sample is finally working! (also HW mipmap generation is)

DynamicCubemap.jpg