* The definition is specifically using chained min/max which return the other
argument if one is NaN, so a NaN being saturated is guaranteed to return 0.
* On D3D the implementation was severely complicated by two parallel paths - one
that 'flattened' vec4s out into easy-to-consume format for debugging. Instead
we do this as a post-process transformation now in the debugging itself.
* Similarly D3D's implementation used DXBC data directly to fetch data, when all
of the information needed is in the ShaderConstant arrays and used by Vulkan.
This allows us to share the implementation.
* Only GL still needs its own implementation since it needs to query the API for
offsets etc as it can change unreliably and can't easily produce a standard
reflection data. We do share the 'read from buffer data' implementation
though.
* For D3D11 byte offsets are always uint32 aligned, but for other APIs that's
not guaranteed. Storing a byte offset is strictly more expressive and a lot
simpler to reason about.
* We also pick the output pixel in the CBuffer_Zoo tests to ensure the API
agrees with our interpretation of the data.
* Follow-up commit will tidy D3D cbuffer code that needs it.
In the capture-time tracking of resource usage, this change adds information on
the offset and size of accesses to Vulkan VkDeviceMemory. This information is
curretnly discarded, but will be used in a later change to implement
finer-grained usage tracking for VkDeviceMemory.
This change simplifies the `FrameRefType` enum by removing the separate states and
transitions, and replacing them with a smaller set of reference types, together
with functions that compose those reference types.
This change also introduces a `Clear` reference type, which is used to represent
an access to the resource that completely overwrites the previous contents; this
is in contrast with a `Write` access that may leave some of the previous
contents untouched.
* We need to locate it before setting the toolchain file, so checking when
building renderdoccmd is too late. This also lets us print where the SDK/NDK
is found, and add error messages if we don't locate it properly.
Intel published a performance query extension support defined back in
2013. This is available on Windows & Linux (in the Mesa driver). This
should provide the same types of counters as the MDAPI backend for
DX11.
Frameretrace [1] (a fork/branch of Apitrace) uses the same extension.
v2: Fix build without OpenGL
Simplify logic to enable counters
Warn about non enabled counters on Linux/Mesa
Generate counter Uuid
v3: Turn asserts into errors
Don't load perf entry points manually
v4: More clang-format
v5: Fix some Windows conversion warnings
v6: Fix errors on Windows where the driver reports an error on
glGetPerfQueryInfoINTEL as a mean to say that the queryId cannot
be used through the extension
v7: clang-format
v8: Initialize variable passed by pointers to GL entry points
v9: Only try to use the INTEL_performance_query on Mesa, experience
shows the Intel Windows driver doesn't report anything useful.
[1]: https://github.com/janesma/apitrace/wiki/screen-shots
* Nomachine is one program that requests these, but has a fallback path for if
they're not available. Denying the request makes things more compatible.
Haiyu Zhen