* This is not the default python layout but is convenient for sharing the
standard library .zip and include folder with separate binary folders per-
platform. The layout mirrors what we include in the repository.
* This is expected to be in a pyside\ subfolder, with an organisation matching
our default setup.
* We also now copy the shiboken2 python module (if it exists) as required by new
pyside2 versions.
* This is the only thing missing from an installed version of python to be able
to build against it, so it's convenient to rebuild it instead of fetching it
separately from the embeddable distribution
* We create both a stubs folder for each specific version, and a 'latest' that
is updated by newer RD versions.
* For development, the stubs will be regenerated any time the git commit hash
changes for development builds.
* This is smaller and easier to maintain, and adds functionality like resolving
circular dependencies to be able to import the stubs as-is on python 3.6+
* Some markers from the application may be unbalanced, or it might be unbalanced
if we began the capture with some markers already open (e.g. due to a push/pop
around present).
When MRTSS is used, resolveImageView must be NULL since resolve happens
into the same image:
> VUID-VkRenderingAttachmentInfo-imageView-06863
> If imageView is not VK_NULL_HANDLE, resolveMode is not VK_RESOLVE_MODE_NONE,
> the pNext chain of VkRenderingInfo includes a VkMultisampledRenderToSingleSampledInfoEXT
> structure with the multisampledRenderToSingleSampledEnable field equal to
> VK_TRUE, and imageView has a sample count of VK_SAMPLE_COUNT_1_BIT,
> resolveImageView must be VK_NULL_HANDLE
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
* Debug info could theoretically contain names which include path like
characters including '.' or '[]' even though these wouldn't be valid
identifier names. We assume this will not happen with names that are part of
structures/arrays themselves but instead only happen if there's a single
matching path.
* If there is no set/space and no array index, a single number is unclear of
what it actually means (when there is no sampler object, we don't have
anything to refer to except the binding).
* Because Qt is awful at customising controls, the functions used to fetch the
index of sections are not virtual so the internal QHeaderView version doesn't
get the right sections when we have column grouping enabled.
* Newest VS2026 dropped support for the entirely working v140 tools for zero
good reason: https://developercommunity.visualstudio.com/t/Visual-
Studio-2026-188-update-removes-v/11121716
* This then breaks our CI since we can't install the toolset manually. After
lots of dancing, this set of magic words seems to work for now, but who can
say for how long.
* Non-tightly packed arrays can be larger based on the stride than base size
multiplied by element count, e.g. with a 4-byte uint with a 16-byte array
stride.
D3D12EventNode contains all data for an Event during loading: APIEvent, ActionDescription, resource usage, debugMessages, annotations.
Action ID, Event ID is not computed whilst loading is happening.
At the end of Loading when the D3D12EventNode's have been flattened into linear submission order then the D3D12EventNode's are baked into RenderDoc replay APIEvents and Actions. Event IDs and Action IDs are assigned as part of the baking process
- loose event annotation
- a barrier at end of command buffer
- at end of command buffer attached to CommandList Close
- command buffer with no actions, just set marker
- annotations before/during/after ExecuteIndirect calls
baldurk