This adds the NVVulkanCounters class, which implements Vulkan counter
collection on NVIDIA hardware via the NVIDIA Nsight Perf SDK.
Some modifications are made to the NvPerfUtility headers in order to
use the Vulkan dispatch tables from RenderDoc.
On Windows, the VK_KHR_external_semaphore_win32 extension is required
for synchronization with the NvPerf "service pending GPU operations"
thread.
This adds the NVD3D12Counters class, which implements D3D12 counter
collection on NVIDIA hardware via the NVIDIA Nsight Perf SDK.
A helper class NVCounterEnumerator is added to provide functionality
common to NVIDIA counters for other graphics APIs.
Adds the macro NV_PERF_UTILITY_HIDE_VULKAN_SYMBOLS to NvPerfUtility, which
allows for passing Vulkan function pointers without linking with Vulkan symbols
that are not present in RenderDoc.
* When used in richcompare this would throw an exception and return
Py_NotImplemented causing a failure. Instead we should just return NULL, which
is fine and will be considered as a not-equal comparison for
equality/inequality and throw the kind of exception we want for less than or
greater than.
* The root signature is not a good model for what resources are actually used,
instead use the shader reflection as we do on other APIs. In either case this
does not work for bindless access (> 1000 registers).
This patch solves the following Visual C compiler error when attempting to build the "util/tests/demos.sln" VS project from the command-line w/ MSBUILD:
`error C2220: the following warning is treated as an error
warning C4701: potentially uninitialized local variable 'xfbpipe' used`
It appears that on some machines (including mine), the registry key
which contains the installation path to Windows SDK is located under
"HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\...". Update renderdoc project
files to search that key as well.
* Ideally we would also include mesh output here, but we would need a way to
clear the postvs cache every so often to avoid bloating, otherwise it will
generate too much data iterating the whole capture.
* It's unclear if this should be required as the fills and copies don't overlap,
but this is not so perf sensitive that a barrier can't be added for safety.
* Previously with shader feedback being fetched separately we may have had to
replay multiple times to ensure clean results. If we do it as part of the
initial replay on selecting the event this issue goes away and we remove the
extra redundant replay.
Jonathan Glines