This block was a sloppy way of trying to avoid prioritizing lavapipe over another device, but truthfully the only way to guarantee avoiding CPU drivers is to add a property to allow apps to require hardware acceleration.
When the upload needs realignment, a new buffer is created to do the
upload, and the source data is copied to the new buffer. This commit
fixes the issue where the memcopy can read off the end of the source
buffer since it is reading based on destination pitch instead of source
pitch.
When descriptor leaks overflow, the D3D12 SDL GPU renderer fetches more from the pool, but never returns them, which eventually causes an "out of memory" crash.
You must set SDL_PROP_GPU_DEVICE_CREATE_FEATURE_DEPTH_CLAMPING_BOOLEAN to false on this platform, since setDepthClipMode is not supported on Apple headsets (as of visionOS 2.3) and clipping is the default.
VUID-VkPipelineRasterizationStateCreateInfo-depthClampEnable-00782(ERROR / SPEC): msgNum: -316906200 - Validation Error: [ VUID-VkPipelineRasterizationStateCreateInfo-depthClampEnable-00782 ] | MessageID = 0xed1c6528 | vkCreateGraphicsPipelines(): pCreateInfos[0].pRasterizationState->depthClampEnable is VK_TRUE, but the depthClamp feature was not enabled. The Vulkan spec states: If the depthClamp feature is not enabled, depthClampEnable must be VK_FALSE (https://vulkan.lunarg.com/doc/view/1.3.268.0/windows/1.3-extensions/vkspec.html#VUID-VkPipelineRasterizationStateCreateInfo-depthClampEnable-00782)
Found when running in valgrind looking at another issue.
- RenderPass' depth_stencil_target
Tripped in SDL_BindGPUFragmentSamplers when not binding a DS target
- VulkanCommandBuffer's swapchainRequested
Tripped in VULKAN_Submit for the end transition barrier when
creating an image. The field is only reset when reused, not on first
use
We previously thought this wasn't possible because constant buffer offsets and
partial updates were unavailable, but we were reading the wrong table - this is
only the case for D3D11...
https://learn.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-devices-downlevel-intro
... while 12 doesn't list this feature at all:
https://learn.microsoft.com/en-us/windows/win32/direct3d12/hardware-feature-levels
We double checked and Jesse Natalie confirmed that this feature is required for
D3D12 even for 11_0 drivers. (Thanks Jesse!)
Additionally, D3D12 requires that UAVs are accessible from all shader stages,
meaning Tier 2 is enough to support the number of UAVs we need. Tier 1 could be
a property to lower the requirements, but that can be done later.
When skipping presentation due to the window being hidden, presentDataCount is not incremented on the command buffer, and subsequently the submitted command buffers will not be cleaned up as long as the window is hidden. This results in a lag spike when showing the window due to all previously submitted command buffers suddenly being cleaned up at once, and lag at shutdown due to an equivalent number of fences needing to be destroyed.
Instead of relying on presentDataCount to determine whether a command buffer should be cleaned up, use a flag, which is set under the appropriate circumstances.
