* Normally we require this for display, but we can't display these formats. On
many drivers sampling is not supported so this would force the whole format to
be unsupported, but due to shaderImageInt64Atomics we can't do that.
- Access queryTests, queryTestsMS element one instead of zero
- add tests for texBuffers, storeTexBuffers
- initialize arrayed resources descriptors to bad values
- set the accessed array indices to good values
* 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.
Jake Turner