Vulkan-docs: How can a left-handed NDC space be supported?

[johnkslang]

This is a transfer of glslang issue 494, as it sounds this is the correct place to address it.

In particular, see these comments:

• https://github.com/KhronosGroup/glslang/issues/494#issuecomment-243993159
• https://github.com/KhronosGroup/glslang/issues/494#issuecomment-244690458

[NicolBolas]

If this is going to be a core requirement of a future Vulkan 1.1, then I say that we should also require Vulkan to support OpenGL conventions. It'd be silly for Vulkan to require all implementations to support D3D12 conventions, and provide compilation from GLSL (though glslangValidator and SPIR-V), but without supporting the actual OpenGL conventions.

If this is only going to be exposed via an extension, then D3D12-only seems reasonable.

[Novum]

Note: This is a rant

I have said this before, but this is something that should never have happened. To my knowledge all other platforms use a common convention. Therefore I do not believe this was any sort of hardware limitation that forced Vulkan to be different.

Just support the D3D12 convention and be done with it. All the coordinate systems should be industry standards. Nobody has time for shenanigans like this and there are zero benefits to be different.

I strongly believe there are other, way more important issues to solve.
Axel

[NicolBolas]

To my knowledge all other platforms use a common convention.

I just realized that you're absolutely right (thus making my above point superfluous).

Direct3D 12/11/10's NDC conventions actually _are_ OpenGL's conventions (using the [0, 1] depth range that GL 4.5 allows, of course). And I verified that Metal also uses the same left-handed axis conventions. So Vulkan really is the odd one out here.

Unfortunately, since Vulkan 1.0 shipped this way, it must be supported until 2.0 ships. Otherwise, it'd be a backwards-incompatible change.

[DominikWitczakAMD]

AMD will shortly be releasing a Vulkan extension called VK_AMD_negative_viewport_height which is going to allow applications to flip along the Y axis during viewport transformation.

[hrydgard]

Viewport in hardware is really a scale factor + translation, rather than x/y/w/h. If it was specified that way (centerX, centerY, scaleX, scaleY) instead of x,y,w,h, support for flipping the view by both X and Y would sort of fall out neatly automatically. A bit late to change that now though I guess. Of course, changing the backface culling order to match is always an issue...

[ghost]

Surprised this hasn't been closed - VK_KHR_maintenance1 added the ability to select a negative viewport. Think this can be considered dealt with? Please re-open if anyone thinks there are still issues to address...