Gfx: Viewport and scissor first sets

[msiglreith]

Vulkan allows setting individual viewport and scissors.
Requires caching in the dx12 backend.

[HybridEidolon]

For clarity, this is referring to vkCmdSetScissor, vkCmdSetViewport on Vulkan side, ID3D12GraphicsCommandList::RSSetScissorRects, ID3D12GraphicsCommandList::RSSetViewports on d3d12, and MTLRenderCommandEncoder#setScissorRect(s?), MTLRenderCommandEncoder#setViewports(s?) on Metal, correct?

Here's some notes for whoever implements (likely me, since I'm reading this while bored at work...)

Relevant API docs:

• https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkCmdSetScissor.html
• https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkCmdSetViewport.html
• https://msdn.microsoft.com/en-us/library/windows/desktop/dn903900(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/dn903899(v=vs.85).aspx
• https://developer.apple.com/documentation/metal/mtlrendercommandencoder/2928168-setscissorrects
• https://developer.apple.com/documentation/metal/mtlrendercommandencoder/2928178-setviewports

Vulkan's interface allows setting N scissor rects or viewports from some starting index in a command buffer. As mentioned, D3D12's version of this requires you to specify all the scissors and viewports at once, so D3D12 command buffer impl will have to keep track of the currently recorded scissors and viewports and submit the full, changed set of scissors and viewports. Metal also has the same restriction, so I think the metal backend tag should be added.

Implementor's job is to provide an equivalent or modified versions of RawCommandBuffer::set_scissors and RawCommandBuffer::set_viewports and CommandBuffer functions allowing setting from a starting range, not just from 0. This cleanly maps to Vulkan's commands and can thus be used for Vulkan Portability.

Question: What should happen if the caller tries to manipulate a scissor or viewport that hasn't already been defined somewhere in the command buffer for D3D12 or Metal? Only Vulkan has an actual notion of inline or baked state for these, and Vulkan does not require specifying defaults for these in PSO construction (if the requisite dynamic states are set). Should providing viewport/scissor state during pipeline creation be required?

[msiglreith]

Should providing viewport/scissor state during pipeline creation be required?

nop.
I'm not fully sure if I understand the part before correctly. Either the viewports are baked already in the PSO, in this case nothing needs to be implemented, this is already handled. For dynamic state the viewports and scissors needs to be cached and set before draw. The whole range from 0 up to the number of viewports/scissors must be set before executing a draw call following the specification.

[HybridEidolon]

I have the code for this complete for vulkan, gl, d3d12 and metal, all tested on windows and macOS, just waiting on the ash issue to be closed so I can point backend-vulkan to the new version.