Keep the argument tuple owned by varfunc for its full per-call lifetime.
ConvertFunc destroys varfunc before ScopedFuncCall, so the tuple is released
exactly once while the GIL is still held, including failed callbacks.
Clear the argument tuple after calling a Python callback so varfunc's
destructor cannot decrement it a second time. This prevents repeated
zero-argument callbacks from losing references to the shared empty tuple.
Skip callback reference cleanup after Python has shut down, since Qt can
destroy pending callback closures during QApplication teardown.
Validation:
- Regression harness using this header and bundled Python 3.6.4: 20,000
callbacks with balanced references, nonempty arguments, exception paths,
deferred release, and callback destruction after Py_Finalize.
- Windows x64 Release build: no warnings or errors.
- MI 8 remote replay: 1.rdc -> 2.rdc -> 1.rdc -> 2.rdc; normal exit with
a pending callback, exit code 0.
Build and device checks used the existing development checkout, which also
contains separate local changes excluded from this commit.
* In some cases for resources that are declared in the entry point they will be
in reflected but it is possible that they are not statically used. For these,
it is allowed for them to not be present in the descriptor set at which point
we need to ignore them.
* 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.
James Sumihiro