* Anything obtained via the aliased interfaces will act as if it's a List[], but
any globals from the repl will be rdcarray typed so we need to handle looking
up the 'real' type for that.
On some Qualcomm drivers (observed on Adreno 740, Xiaomi 2304FPN6DC,
Android 16) vkAllocateMemory returns an address different from the
requested opaque capture address when the pNext chain lists
VkMemoryOpaqueCaptureAddressAllocateInfo before
VkMemoryAllocateFlagsInfo carrying
VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT. The allocation
itself succeeds, so replay only fails later at the post-allocation
address equality check ("opaque address 0x%llx has changed on replay").
A standalone NDK Vulkan probe that replays the captured allocation
sequence without any RenderDoc layer involved deterministically
reproduces the wrong address with the captured chain order, and gets
all addresses matching when the two structures are swapped. pNext
chain order is not supposed to affect behaviour, so this is a driver
bug.
Move the existing VkMemoryAllocateFlagsInfo node to the head of the
chain when the new QualcommBrokenOpaqueCaptureAddress driver
workaround is active, immediately before AllocateMemory. The captured
address, flags, and all other chain nodes are left untouched, and the
existing address equality check still applies. The workaround only
triggers when both structures are present, a non-zero opaque address
is requested, and the flags node is not already first, so unrelated
captures are unaffected. The flag is enabled unconditionally for
Qualcomm for now as the fix version is unknown, matching the other
Qualcomm workarounds.
Validated on the original failing capture: remote replay of a
33 MB frame that previously failed the address check now opens in
~2.7 s and replays through Present with matching addresses.
According to the D3D12 debug layer, setting either BufferLocation or
SizeInBytes to 0 in IASetVertexBuffers and IASetIndexBuffer commands
causes a null view to be bound, with the rest of the VBV/IBV description
structure being ignored.
In particular, this means that a BufferLocation of 0 must be supported
by RenderDoc, and also if SizeInBytes is 0, BufferLocation may be an
invalid address, so it must be ignored.
This change disables the resource lookup for null VBVs and IBVs.
Additionally, if the application has provided an invalid address for a
non-null VBV or IBV, it's replaced with a null view now instead of
passing the original address from the application through.
- compute any bitmasks using subgroupBallot() outside of flow control
- add tests for subgroupBallotBitExtract, subgroupBallotFindLSB, subgroupBallotFindMSB
As far as I can see, OpGroupNonUniformBallotBitCount,
OpGroupNonUniformBallotBitExtract, OpGroupNonUniformBallotFindLSB
and OpGroupNonUniformBallotFindMSB all work directly with the
ballot value without filtering the bits for active lanes
(https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpGroupNonUniformBallotBitCount).
With Nvidia 610 drivers this can also be confirmed by printing the
shader values. This should hopefully fix these operations.
The sampling shader writes in the textures native format. Rather than
invalidly converting all formats to float, create a separate a separate
render path for each base type. All of the paths render into a single
mutable format image.
This fixes VK_Shader_Debug_Zoo, Section GLSL1, Test 180 when running with
KosmicKrisp and avoids a Undefined-Value-ShaderFragmentOutputMismatch
warning from validation.
* For draws where some fragments discard, D3D12 & Vulkan currently can't
distinguish which specific fragments did and didn't discard because they're
processed batched in separate callbacks rather than incrementally like D3D11 &
GL which can track a discarded offset by doing one stencil count at a time.
This means we can't get primitive information or ordering, we only get a list
of the passing fragments and a set of failing fragments.
* Note that on all APIs we also can't distinguish when instancing is present,
because there could be multiple "identical" primitives from different
primitives, some of which discard and some don't.
* In pixel history we don't want to remove things like the depth op for the
postmod pipe which executes with the normal depth op and we won't have
replaced it yet.
The initialization path for both the capture and replay layers were
modifying a global `static` structure containing `VkApplicationInfo` to
update it when `Vulkan_Debug_ReplaceAppInfo` is enabled (the default),
and also always to pass through the most accurate `apiVersion` from the
caller instead of defaulting to a minimum.
Worse, code after `vkCreateInstance()` was reading back the value for
`apiVersion` passed through this global constant (rather than reading
the local copy).
The end result is that, at least on Android where 3 instances are
created at roughly the same time _on three different threads_ (as seen
in the logs captured in #3903) they all clobber this global state and
because `vkCreateInstance()` could easily take some time (4-12ms) those
threads would be reading back each others' `apiVersion`.
In turn when the last write to `renderdocAppInfo.apiVersion` is lower
than what an app originally set and expected based on the queried Vulkan
instance and physical device versions, all kinds of weird things happen
when expected promoted-to-core extensions are no longer treated as
available by RenderDoc [^1].
[^1]: A good example is an app enabling Ray Tracing extensions on a
Vulkan 1.2+ device: the buffer_device_address extension is in core
here and not explicitly enabled by at least our application, but if an
instance initializer for Vulkan 1.1 "won" the race condition (that's
the version `android framework` uses as of writing, even on Android 16)
RenderDoc doesn't load the extension function pointers. Ray Tracing
(currently) forces RenderDoc to query BDA for every buffer and crashes
at the first occurrence on a NULL PFN. Similar NULL pointers occurred
in our app when relying on `vkWaitSemaphores()` from the promoted
`VK_KHR_timeline_semaphore` extension for example.
The most trivial and correct solution is to no longer update this global
state, but instead keep it as `const` data and copy it to the stack for
modification and passing through to `vkCreateInstance()` without ever
leaking `apiVersion` outside of the calling function.
For empty draws, VulkanDebugManager::PatchLineStripIndexBuffer() can end up
with an empty list of patched indices, which it then tries to put into a 0
length index buffer. The only caller of this method only uses the index buffer
if the returned indexCount is > 0, so this is wasted work.
Creating a 0 length buffer violates VUID-VkBufferCreateInfo-size-00912 and
fails on KosmicKrisp. Other mesa drivers silently round the size up to 4096
bytes, the minium allocation size for kernel mode drivers.
This is triggered by check_empty_draw_overlays() in the VK_Indirect test.
Jake Turner