Use the cached Texture Description for all other Textures which matches the behaviour of GetTextureData()
When saving a texture when a custom visualisation shader is in use:
- fixes a crash when saving as HDR or EXT
- fixes incorrect image saved to DDS
* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
* For OpenGL we need to remap a 3D block-compressed texture to a 2D array for
display, when doing so we need to account for the mip size when calculating
the size of each chunk of data.
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
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.
* This is a consideration for any cases where binding numbers are relevant -
primarily D3D11 and GL - where the offset into an arbitrary (and possibly
fake) descriptor storage is not helpful but knowing the register binding
definitely is.
* If someone wants to look at the raw descriptor contents without respect to a
particular shader access they can use this query to determine a more useful
'name' for any given descriptor. On D3D11 and GL this gives the register
number, on Vulkan it gives the binding number (and array element). On D3D12 it
just repeats the offset effectively.
DebugShaderInputs struct contains existing the parameters:
sample
primitive
and a new parameter
view
Default constructor for DebugShaderInputs sets the parameters to NoPreference (~0U).
* We add a capture option that defines a soft limit we aim to keep under for
memory overhead during capture, excess initial states after that will be
stored temporarily on disk.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* Newly written shaders and any updated shaders can now use pre-defined macros
to abstract away binding differences between APIs, so custom shaders will be
more portable in particular shaders written in HLSL for D3D or GLSL on OpenGL
won't break on vulkan because they refer to incorrect binds.
* If we hit a fatal error during initialisation, the structured file pointer
still points at the temporary serialiser's structured file. It's not until we
finish loading that we swap it into the driver-stored file that we can safely
return and detach ownership of.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* These are the only handles returned up by reference from the replay driver,
dynamically allocating them means that we can steal/move the ownership of
these and keep them valid even after the replay driver is destroyed.
* Note - ShaderDebugTrace is also returned by reference but it is already
dynamically allocated like this.
* Instead of storing the API pipeline states in the replay driver and returning
pointers, we store them in the replay controller and write into it from the
replay driver.
* This will allow us to remove the replay driver and still keep any previously
obtained references/pointers to the pipeline state valid.
* This is a deliberate break of compatibility since the field is now often
empty, for non-markers. This means code will get a more explicit error when
the name is being referenced, so it can be updated to fetch the name it needs
as needed.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
baldurk