viewport and clipping rectangle

[pollend]

I've been debugging a problem where the viewport region doesn't seem correct, but the scissor rectangle works doesn't work how I expect it to work. so passing in a negative value for y seems to place the viewport rectangle in the correct place I was expecting. so y would move the viewport above the screen through my testing. I was wondering if this is just me or an inconsistency with the vulkan implementation or is this expected behavior.

[dzhdanNV]

Many years ago (probably) there was a discussion about it. If I remember correctly, the idea was to make VK (it's VK, right?) closer to D3D. D3D window origin is upper left, VK window origin is lower left. I don't remember and can't verify right now, but we make VK origin upper left to avoid divergence. What's your expectation here, what's origin do you expect? Can the problem be reproduced in an NRI sample? (will get back to my PC on Monday)

[pollend]

I'm using a negative y value for the origin. Top down is negative and left to right is positive., but the clipping rectangle is as expected. Doesn't look like it's expected behaviour.

[dzhdanNV]

Several comments:

• as I said, NRI assumes top-left origin to match D3D behavior
  • I will add a clarification about it into the NRIDescs.h
• viewport vertical flipping code in VK implementation is wrong. This is the correct one:

  // Flip
  vkViewport.y = viewport.height + viewport.y;      // <=== "-" in the current version
  vkViewport.height = -viewport.height;

  • @pollend please, let me know if the fixed code is not enough for you, because you want to stick with the bottom-left origin. It can be easily done for VK at least by extending device creation / wrapping desc, or probably even for D3D11/D3D12 if a similar flipping code (but in the opposite direction) works in D3D (haven't tried yet).

[dzhdanNV]

Yes, I will add something like bool viewportOriginBottomLeft to the device creation / wrapping desc (false is an implicit default, matching the current behavior). If it's set to true VK and D3D12 will switch to the bottom-left origin, while D3D11 will have to report an error (there is no an easy way to change the viewport origin).

Viewport inversion in D3D12 has been added in a relatively old Agility SDK (OPTIONS9) - https://microsoft.github.io/DirectX-Specs/d3d/VulkanOn12.html#inverted-viewports.

[dzhdanNV]

OK, I have already tested the following changes:

• Fix flipping code in VK (obviously, it's a mandatory requirement)
• Add isViewportOriginBottomLeftSupported to DeviceDesc
  • D3D11: unsupported
  • VK: supported
  • D3D12: requires AgilitySDK and options13.InvertedViewportHeightFlipsYSupported

• Add bool originBottomLeft to Viewport as the last field of the struct

  • unlocks maximum flexibility
  • should be a non-breaking change
  • under the hood:
    • VK: flips Y if originBottomLeft = false
    • D3D12: flips Y if originBottomLeft = true

  What do you think?

[pollend]

Seems good to me. Thanks for the quick response. umm, i don't think you need to do this change bool viewportOriginBottomLeft. Is there any reason to do this beyond just legacy behavior? I don't really need to move the viewport origin to the bottom left not sure if this is going to be a common use case at all. at worse people can easily flip the origin in the logic.

[dzhdanNV]

In v1.153:

• fixed Y-flipping code in VK implementation
• added support for bottom-left origin by extending Viewport struct

Please, check on your side.

[dzhdanNV]

i don't think you need to do this change bool viewportOriginBottomLeft

For your case you only need to update to the latest. The flipping bug has been fixed in the VK implementation. When you passed -y you compensated wrong behavior, so:

(OLD) vkViewport.y = viewport.height - (-viewport.y) == (FIXED) vkViewport.y = viewport.height + viewport.y

I just went further, what if someone uses NRI in an already written app with the old-school OGL-like viewport origin (it affects shaders and potentially even matrices), now NRI should support this too in both VK and D3D12.