Support shader exported depth by replaying using the capture pixel shader to determine passing pixels
Don't write depth or stencil during the reply of failing pixels
No need to restore depth-stencil after replay of failing pixels
An orphaned window has a NULL parent.
An orphaned window is unable to be re-opened if it already exists in m_ToolWindows because when it tries to raise the existing window it does not have a valid parent
Previously, the SDK tooltip was inconsistent between the label and the
text field/button, with the latter incorrectly saying the location of
adb.exe should be used. There also was no description at all for the
JDK option.
I've copied the descriptions from the RDOC_CONFIG macros in
android_tools.cpp, which should make it easier to set these correctly.
It's currently forcibly disabled via 'check_support' because it's known
to fail due to the fact that the commands are always serialised and
replayed in submission order instead of the order that respects queues
blocked on fence waits that get signalled later from other queues.
The pixel data has been serialized as pure bytes with no padding or packing.
It was already handled in:
glTexSubImage1D
glTexSubImage2D
glTexSubImage3D
glCompressedTexSubImage1D
glCompressedTexSubImage2D
glCompressedTexSubImage1D
Apply the same handling to:
glTexImage1D
glTexImage2D
glTexImage3D
glCompressedTexImage1D
glCompressedTexImage2D
glCompressedTexImage3D
These APIs do not handle a non-zero offset with the GL_PIXEL_UNPACK_BUFFER
The get query results uses VK_QUERY_RESULT_WAIT_BIT option which makes destroying the query pool safe (the validation layers must not handle this case or it isn't specified behaviour).
This change adds a GPU sync which removes the following validation error. The GPU has already been waited on by the queries using VK_QUERY_RESULT_WAIT_BIT options.
Validation Error: [ VUID-vkDestroyQueryPool-queryPool-00793 ] | MessageID = 0x5ef3bf2b | Cannot call vkDestroyQueryPool on VkQueryPool 0xf49d4000000029b[] that is currently in use by a command buffer. The Vulkan spec states: All submitted commands that refer to queryPool must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.261.1/windows/1.3-extensions/vkspec.html#VUID-vkDestroyQueryPool-queryPool-00793)
This tests submitting commands, signals, and waits to graphics and
multiple compute queues where the entire frame's submission for each
queue depends on the other queues and the submission order is not the
order in which the GPU (and replay) need to be processed. This is to
ensure any capture or replaying deserialises adequately.
Added 'D3D12BufferCreator::InitialState(D3D12_RESOURCE_STATES)' to allow
user code to avoid adding unnecessary transition barriers after resource
creation.
Added 'D3D12TextureCreator::ClearVal(const D3D12_CLEAR_VALUE &)' to avoid
a PIX performance warning/tip about clearing resources that haven't had
their clear value set on creation.
* When we detect a new version of Android and a 64-bit device where the 32-bit
version of RenderDoc fails to install completely, ignore this and don't warn
the user about it.
New Binding 3
Initial size is UINT32_MAX
Updated to be sized DESC_ARRAY3_SIZE
Used in the shader to ensure the binding is referenced
Stress tests the FetchShaderFeedback code when it computes the maximum size of feedbackStorageSize.
* Prefer vendor-neutral extension aliases for enums over vendor-specific.
* When disassembling opcodes with optional parameters, only include the
parameters when present.
Compiles the demo APK with -Wno-deprecated-declarations when the NDK is v26 or over, otherwise it fails to compile the fmt core header. In the LLVM version used in the NDK, using std::char_traits with non-std types is marked as deprecated.
* Fixed issue where a previously built demo APK would be added into the APK archive upon next build
* Correct the functional test's --in-process help output
* Descriptor heap tier limits are not very useful as even tier 3 might be as
limited as tier 2. Previously expanding a small amount was safe but newer NV
drivers or systems seem to have stricter limits than before.
* When we're sourcing from our own texture we don't want to bring in any
typecast to unorm/uint/etc from the original texture's view. This already
happens for the main display but we also need to do that for the thumbnail
context.
* A weight of 300 seems to cause weird problems like it allowing comments to
stretch beyond the column limit even if they're the only thing on a line in a
block. A value of 200 avoids this without reformatting any other code (phew!)
This adds the next step toward D3D12 pixel history, which is mostly
the generic action callback that is used for other replays later
(similar to how Vulkan pixel history operates).
Jake Turner