* This doesn't seem to be documented anywhere but some applications rely on it
and it seems like PIX behaves this way, so it is as with many things in D3D
the defacto standard
Destination copy buffer was sized to the number of events, this did not guarantee enough storage for the per fragment data i.e. small number of events with large of fragments per event
Reserve space for at least 256 fragments or 128 events in the buffer
Do not get data for fragments if the buffer does not have enough space
In the problem case the buffer went from 4KB to 28KB
Do not pixel debug on an unknown primitive ID (-1)
Allow pixel debug and vertex debug on non-drawcall actions which have non-zero drawIndex i.e. Indirect draws
If the pattern's dimensions are not an integer multiple of the format's block size, then do not attempt to create the discard pattern, just exit early.
Fixes 3466
When renderdoc opens an image file, it treats it as a
"somewhat special" capture. However compressing it only corrupts
the source image file, without doing anything useful. So disable
that menu item for "image" captures.
Move all of EXR reading/preparation code into load_exr_from_file,
similar to how load_dds_from_file is done.
ImageViewer::RefreshFile code now uses very similar flow
for both DDS and EXR files (i.e. "what can have mipmaps")
All places that used is_exr_file already had first four bytes
of the file read into memory. So make is_exr_file work just
like is_dds_file does and check those bytes directly, no need
to hit stdio again.
Tiled EXR files can have mipmaps levels. When they do,
and the odd size rounding mode matches what all the
graphics APIs do ("round down"), load them when loading
the exr file. Using the same machinery that the DDS
mipmap loading uses.
And move it out into a tex_data.h header. This is in preparation
for getting mipmaps out of EXR files, where read_dds_data for
that would be a bit confusing.
A tiny bit faster, and I think it is easier to understand too.
Time taken to load 4K video resolution EXR files, on Ryzen 5950X/VS2022:
- FP16 file (27MB): 77ms -> 75ms
- FP32 file (69MB): 118ms -> 113ms
EXR files internally are split into independent "parts", which can
be decoded separately. Tinyexr already supports that via
TINYEXR_USE_THREAD.
Time taken to load 4K video resolution EXR files, on Ryzen 5950X/VS2022:
- FP16 file (27MB): 536ms -> 77ms
- FP32 file (69MB): 793ms -> 118ms
Various EXR images especially from movie assets do not simply have "R"
etc as channel names; the convention seems to be to have "layer name",
".", "color channel name". For example, channels in EXR might be
"rgb.R", "rgb.G", "rgb.B", which RenderDoc was not detecting previously
and displaying an all-black image.
Jake Turner