Hi,

I finally managed to get the DX11 emulating Vulkan device working but everything is flipped vertically now because Vulkan has a different clipping space. What are the best practices out there to keep these implementation consistent? I tried using a vertically flipped viewport, and while it works on Nvidia 1050, the Vulkan debug layer is throwing error messages that this is not supported in the spec so it might not work on others. There is also the possibility to flip the clip scpace position Y coordinate before writing out with vertex shader, but that requires changing and recompiling every shader. I could also bake it into the camera projection matrices, though I want to avoid that because then I need to track down for the whole engine where I upload matrices... Any chance of an easy extension or something? If not, I will probably go with changing the vertex shaders.

There's some extension mentioned, but they probably talk more about GL/VK compatibility: http://anki3d.org/vulkan-coordinate-system/

Personally i had to change back/frontface culling mode when moving to VK, but maybe projections too.

I flip the coordinates in my vertex shader, but I also generate my shaders from another representation, and the fixup happens "automatically". A similar fixup is done in my OpenGL shaders to reconcile the clip-space differences there (z-range).

Thank you both, for the time being I will go with flipping in the vertex shaders. Though I have no system in place, I will have to manually add that with a SPIRV macro. This way I don't have to mess with culling direction.

Hi turanszkij, I have different matrix projection methods in Matrix4x4 class:

Matrix4x4::PerspectiveFovVulkan

Matrix4x4::PerspectiveFovDirect3D(also can be used for OpenGL)

Matrix4x4::OrthoVulkan

Matrix4x4::OrthoDirect3D

My implementation Direct3D11Render/VulkanRender/OpenGLRender knows wich methods of Matrix4x4 need to call.

On ‎20‎/‎04‎/‎2018 at 8:52 PM, Andrey OGL_D3D said:

Hi turanszkij, I have different matrix projection methods in Matrix4x4 class:

Matrix4x4::PerspectiveFovVulkan

Matrix4x4::PerspectiveFovDirect3D(also can be used for OpenGL)

Matrix4x4::OrthoVulkan

Matrix4x4::OrthoDirect3D

My implementation Direct3D11Render/VulkanRender/OpenGLRender knows wich methods of Matrix4x4 need to call.

Interesting idea. I also thought about it but I have problems with: I need to track down every instance of using a projection matrix. And sometimes I don't even use a projection matrix, for example full screen triangle. This results in discrepancy and for those cases I also need to rewrite the shader or flip viewport. Also, I don't want to couple the math lib with graphics api.

Hi turanszkij, 

Quote

 I need to track down every instance of using a projection matrix.

Also, I don't want to couple the math lib with graphics api. 

Anyway, if you have multi graphics rendering support, you should resolve any cases with different matrix/viewPort/clipping in the Rendering implementation side or in user side. For example, user should set Light Projection matrix for Shadow Map, but this matrix is different for Direct3D11/Vulkan. How to resolve this ?

1) You can add some macro definition to resolve clip cases in your shaders.

2) Call Matrix method renderInterace->CreateProjectionMatrix

I am now facing the exact same problem. I have just tried viewport height negating with VK_KHR_maintenance1 extension and it seems to work fine at least for the main framebuffer. It also works in cases when shaders do not rely on projection matrix, so that my test triangle looks identical in all 4 support APIs.

After updating to the LunarG SDK version 1.1.73.0 I noticed that glslangvalidator has gained this parameter:

--invert-y | --iy invert position.Y output in vertex shader

Sounds like exactly what we need. I haven't tried it out yet though.

I tried out the parameter last night and it does what it says on the can, so that's probably the easiest way to fix it up without having to flip the coordinate manually in the shader code.

Not related to this, but I had some very strange issues with glslangvalidator 1.1.73.0 generating sub-optimal SPIR-V, almost as if the spirv-opt step that's supposed to be built into the LunarG version of the program was not run. Anyway, I had to revert to 1.1.70.0, but as it turned out the invert-y parameter is available with that version too :)