* 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.
- Disable GL and GLES drivers on GGP
- Add flags to keep symbols in release builds. Adds
minimal debug info that preserves backtraces.
- Disable python modules and qrenderdoc for GGP
* This means that allocating >2GB in a bytebuf doesn't crash. There was no good
reason for the int32_t - that dates back to the earliest interop structs
defined for communication with .NET
* Python throws an error when enums don't have a pre-existing value, which can
happen for GPUCounter due to hardware specific counters. Instead just declare
as int and allow casting back and forth for values that are pre-existing.
* GLContextTLSData default constructor should be initialised.
* Add some missing deletes in shader reflection
* Call freeaddrinfo after getaddrinfo
* Don't leak if we're reserving 0 bytes in rdcstr over the top of an already
empty rdcstr
* This invokes run_tests.py with any arguments but specifies the renderdoc
module and python module paths automatically. Only works if built within the
project repo itself as otherwise it won't locate the test script
* We also fix a number of issues that could cause incorrect formats to be
generated.
* Test cases added for D3D11/GL/Vulkan to test different struct types. These
aren't automated at the moment because most of the code they're testing is in
the UI itself.
* On replay on macOS we use NSOpenGLContext so we can render to windows.
* We have two windowing systems on mac - one for Metal compatible outputs and
one for OpenGL compatible outputs.
* 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.
* Even if a struct isn't trivial (e.g. it contains a constructor) it can still
be trivially copyable (just POD with memcpy), or trivially destructable (with
no destructor). Make sure we don't fall back to slower copies/destroys for
this case as it's relatively common.
* This is the only way in GL to do rendering from one mip to another. We handle
it and display the whole texture even if it's temporarily constricted, and
display the mip state in the pipeline viewer.
* If the mip state is constricted at the start of the frame capture, only mips
0..MAX will be visible at all and other mips will be assumed to not be valid.
* This allows us to have sRGB as a type hint, and better matches API format
types.
* It's currently impossible and unlikely to ever be the case that srgb is
applied to anything other than UNorm, so having it be independent from the
component type was a degree of freedom that was unused.
ExtObject extends the SDObject structure with helper
methods.
Intervals are used for memory region tracking.
Change-Id: I38198c0a096ed838d527b6526216fb28326ebc89
* We'd previously subtract the bitfield value twice, leading to underflow and
then lots of unknown bits appear to be set. Instead we should clear the bit so
that it's safe to apply multiple times.
Predicate state is displayed in the raster state.
"Draw Call" and "Wireframe" overlays are visible even if predicate doesn't pass.
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
* Supported textures are decoded into standard format of YUVA, displayed
visually with Y in green, U in blue, V in red.
* A new texture display mode 'YUVA decode' has been added which does a default
full-range conversion from YUV to RGB.
* Custom shaders can be used to implement a custom decode matrix.
* We handle 4:4:4, 4:2:2, and 4:2:0, with packed, 2-plane and 3-plane formats,
for 8, 10, 12, and 16 bit depths.
* This covers most common formats but still leaves a few out - NV11, palettised
formats, V208/V408 JPG formats.
* This lets us print what driver is available without opening a capture, useful
for autotest logging.
* We also print the driver version & vendor on capture as well as replay for all
APIs. Previously we were only printing this reliably on replay for GL/Vulkan
but it's useful everywhere for post-mortem debugging.
* This option will now toggle on the behaviour to fill undefined buffer contents
with a marker value, both if they're created without data (it will be zero
filled instead) or mapped with discard (it will keep the old contents
instead).
* There were too many hard to find problems or misconceptions about the buffer
filling for it to be useful. Now it will be opt-in instead.
* This happens at the application's risk since there's no way to know what
effect the vendor extension will have or even if it will work together with
renderdoc's hooking.
By default RenderDoc saves captured frame thumbnail image as JPEG which
is lossy compression and makes it difficult to use as a reference image
for testing. Added an option to save thumbnails in different formats.
In order not to change the binary serialization format of .rdc files, if
the thumbnail format is not JPEG, a default JPEG thumbnail is still
saved in the file header as before, while the actual thumbnail is saved
as an additional chunk in the binary sections list. Older versions of
RenderDoc will just ignore this section and still use the legacy JPEG
thumbnail.
Change-Id: Icbf4fbd629719b49868fb785a656f6c7c9946ef9
If "adb install" command is used with "-g" flag, we may get java.lang.SecurityException on some devices because granting runtime permissions at installation time is only allowed for system apps (however we can enable it in the device's Developer options menu).
Also, pulling APK from /data/app/ may be restricted. We can workaround by copying the APK to a directory which we can access then try to pull the APK from there.
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).
* For pipelines using tessellation or containing a geometry shader we use
transform feedback to fetch the output of the vertex pipeline after these
stages.
baldurk