Chris Djali
Chris Djali
I've got most of a slightly different implementation done locally that avoids the main limitation of this PR, but I still wouldn't consider it something that's likely to remain unchanged...
I've pushed that alternative implementation.
We only want one of #1265 and #1268, and #1268 (this one) is my preferred approach. As far as I could find when I wrote this, which was five months...
We decided fairly early on that having a stack for each piece of state that can be changed separately was going to be bad, even if it was mapped most...
It'd be pretty simple to have the classes that currently allocate viewport and scissor state each frame have a member that holds a single instance that gets updated and reused....
Now for the less time-critical part of the response, I didn't go out of my way to do much performance testing with this branch as I couldn't think of a...
I don't think I found any examples that cared, so I just did what I could to try and make things backwards-compatible on paper by setting things wherever they were...
I think things like `VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT` mostly exist to help with old-API-on-top-of-Vulkan compatibility layers like Zink and DXVK, so I don't think there's necessarily any use case for it with a...
I don't think there is at the moment, but one could be thrown together pretty quickly - you just need to compile the scenegraph, detach a node with a BindGraphicsPipeline...
As an alternative, I've made https://github.com/vsg-dev/VulkanSceneGraph/pull/1268.