* This is a simple test using descriptor indexing in fragment and compute
shaders, with sampled images and storage buffers, including passing bindless
arrays through functions to be sure that's tracked properly.
* There's also a define to turn on a reasonably bad case (though not
worst/extreme) of # of descriptors - roughly 5 million descriptors allocated
in total, with roughly 1 million bound at draw time.
* Each binding element within an arrayed descriptor has a bool indicating if
it's dynamically used or not (which will be set to true if the feedback isn't
available). Each descriptor has a uint32_t indicating how many elements are
dynamically used - which is useful for the UI to hide the root of an array
that has no used elements, or to heuristically decide whether to expand or
elide the contents.
* We use VK_EXT_buffer_device_address where possible to reduce code complexity &
increase compatibility, but when not available we reserve a buffer within the
existing bindings.
* Only array descriptors have the feedback run. Non-array descriptors can still
be dynamically used/unused but it's expected that there is less pressure to
trim the list as this would only account for flow control and there is value
in showing bindings that may be dynamically unused. For arrays the size might
potentially be extremely large (with 'bindless' type arrays) so reducing it
only to the set of used items is important.
* With VK_EXT_descriptor_indexing descriptor sets can be updated while a
submission is going on, leading to potentially parallel access to the
references.
* With VK_EXT_descriptor_indexing, the contents of descriptor sets at bind times
are (conservatively) meaningless as they may be updated/changed right up until
submit time with the right feature flags enabled. So instead of marking
resources conservatively dirty at bind time, we do it at submit time. It's
invalid for an application to except multiple versions of a descriptor set to
get applied, so sampling once at submit time is sufficient.
* The extension is not yet whitelisted as there is no solution currently for
feedback on used bindings or handling of pointers in data structures within
the UI or shader reflection.
* Setting it to empty is invalid for derived pipelines - since we don't want the
index to be 0 we want to use basePipelineHandle. We patched it to -1 before
serialising so the value is safe.
* In theory we should check everywhere on every function otherwise we crash with
a NULL pointer, but figuring out which functions to check is non-trivial in
some cases and there's the risk of false positives with fallbacks available
etc in cases where there are several possible alternatives for a given
function.
* These checks have been sprinkled around in places where it's safe because
there's only one implementation of a function that never made it to core, as
well as the most common problems - glFramebufferTexture2DMultisampleEXT and
glFramebufferTextureMultiviewOVR/glFramebufferTextureMultisampleMultiviewOVR
which comes from users mistakenly replaying a mobile capture on desktop. This
is not expected to work but it shouldn't crash.
* glRenderbufferStorageMultisample and glRenderbufferStorageMultisampleEXT
should be interchangeable, with the only difference being the EXT version
specifies that tile resolves may happen and MSAA data won't be preserved.
* When aliasing the functions RenderDoc will call the core version if available
even if the application called into the EXT, assuming them to be
interchangeable (and in this case the core function is a superset of
functionality). Unfortunately on ARM's driver attachments of different types
are not handled properly and FBOs can fail to create.
* The only available workaround for this is to copy-paste the function
implementation and keep them separate, and assume that the application does
the right thing and ends up with compatible attachments. The app could easily
break in the same way, but at least then RenderDoc is not forcing a bug to be
hit.
* Most cases don't have other text together with a ResourceId, so handle an
isolated ResourceId specially and manually render it.
* Further work - we could cache the name the same way as the RichResourceText
does. So far it doesn't seem to appear on profiling.
baldurk