* This is a leftover artifact from before we had general extended type support
and double was the only non-32 bit type we handled. Now we support most type
formats so doubles are just CompType::Float with 8 byte width
KHR counters come in 3 different scopes (quoting the spec) :
* VK_PERFORMANCE_COUNTER_SCOPE_COMMAND_BUFFER_KHR - the performance
counter scope is a single complete command buffer.
* VK_PERFORMANCE_COUNTER_SCOPE_RENDER_PASS_KHR - the performance
counter scope is zero or more complete render passes. The
performance query containing the performance counter must begin
and end outside a render pass instance.
* VK_PERFORMANCE_COUNTER_SCOPE_COMMAND_KHR - the performance counter
scope is zero or more commands.
The way we're currently using the counters is tied to draw/dispatch
commands so we should only use the SCOPE_COMMAND type of counters.
* We still check available features to know which shaders we could create on
replay, to determine whether we should add STORAGE_BIT to MSAA images we want
to store into.
Also:
- support for choosing mip level and slice
- tests for secondary command buffers
- adds a callback around vkCmdExecuteCommands
- refactors pixel history occlusion callback into its own
callback. Allows processing fewer events later on, and getting colour
information separately.
- keep track of subpassContents for vkCmdBeginRenderPass (inline or
secondary)
Renderdoc seems to somewhat require time units to be in float to be
able to present prettyfied results (ms/us/ns).
We were assuming that but a couple of errors slipped in :
* we were asserting that KHR time units are floats
* we didn't describe the renderdoc units as double (even though we
forced the conversion later on)
While we always use an 8 byte storage within renderdoc, the KHR
storage can be of multiple size & type.
The issue was that we were storing a counter in double but then
reporting the type in uint.
To fix this use the KHR storage type to figure the renderdoc type. The
byteWidth size remains always 8 bytes within renderdoc.
For Vulkan pixel history vkCmdEndRenderPass and vkCmdNextSubpass
can represent a modification, since it might be doing an implicit
image resolve. Pixel history is using drawcall callbacks to figure
out values pre- post- events, and vkCmdEndRenderPass and
vkCmdNextSubpass might be such events.
Also adds clear image usage to vkCmdBeginRenderPass(2) for images that
have VK_ATTACHMENT_LOAD_OP_CLEAR.
At this point we don't have Intel GL counters. But the current logic
assumes there is only AMD ones (and that if it's not AMD's, it must be
the generic ones).
* This measure the number of samples that pass the depth/stencil tests -
In the case of early tests, this means it doesn't account for shader discard before writing.
* In many cases (particularly on D3D11/D3D12) the replay would simply
forward functions as-is to the debug manager for implementation. This
meant that change any of those function signatures required more
tedious copy-pasting than was necessary, and didn't make much sense.
* Now the replay class is responsible for implementing all the
functionality and owns any debug-only API resources, but can still use
the debug manager for any indirect utility functions like caching,
etc.
* The API resources are better organised by task in the replay class
rather than being all over the place.
* Finally on vulkan, added some helper functions to reduce the
boilerplate involved in initialising objects.
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* Previously we'd cache a copy of each command buffer at load time, and
submit it any time we're not partially re-recording. This has a couple
of drawbacks though:
- Technically we do some things that invalidate those command buffers,
like updating descriptor sets (with initial state application) and
so for 100% correctness we'd need to re-record.
- It also means that any edits we apply, like modified shaders, don't
properly apply to the whole frame, they only apply to whichever
command buffer is currently being partially recorded.
* We refactor out the 're-record all commands' behaviour previously
reserved just for applying GPU counters, and use that for re-recording
any command buffers that are wholly or partially submitted. Note that
it's still true that only one primary and one secondary at most are
actually *partially* re-recorded. The others are re-recorded in their
entirety.
* This gives a little nicer syntax, a bit better type safety, and also
reflects better for SWIG bindings. Overall it's a minor change but
better.
* We don't update the C# UI at all, since it's soon to be removed and
not worth the effort/code churn.
* For now so we're ABI compatible with C#, all enums are uint32_t, but
that is an obvious optimisation in future to reduce struct packing.
* We avoid 'None' as an enum value, because it's a reserved word in
python so will cause problems generating bindings.
baldurk