Use the same logic as TextureViewer to determine if the target is a depth target
Fixes issue of pixel history on typeless target cast to UNORM and used as depth i.e. shadow map
* This shifts from reporting from the old style bindset/bind to the new system
of only referencing by shader interface and index (independent of binding
model).
* The vulkan shader debugger re-uses the replay interface to cache descriptor
access and descriptor contents in a fashion friendly to interface-index
lookup.
* These are temporarily given separate names, to allow them to exist in parallel
with the existing helpers, but in future these will be renamed when the older
helpers are removed.
* 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.
* Baking these into descriptors when we get arbitrary 'GetDescriptor' queries
independent of the bound descriptor sets is not possible - a descriptor set
could be in theory bound twice to two places with different dynamic offsets.
* Instead we report these as part of the pipeline states and the abstraction &
replay API consumer will need to manually apply them to get the true buffer
offset.
* The offsets are indexed by descriptor storage byte offset for easier
processing (the dynamic offset struct can be turned into a pair and used to
initialise a dict)
* This doesn't change our minimum specs as we already required GCC 5, clang 3.4,
which fully support C++14. Interestingly only VS2015 is the odd one out but we
don't rely on any features from C++14 that it doesn't support.
This message can be seen if the USB cable connecting the device is
removed while the `adb install` command is running. (I ran into this
by accident due to a low-quality cable.)
The previous message was this:
> Failed to install Android remote server for unknown reasons: Couldn't install APK(s). stderr: adb.exe: device '00000a740f4e6d93' not found
> .
>
> lease check that your device is connected and accessible to adb, and that installing APKs over USB is allowed.
This does also include a newline before a period, which looks a bit
strange but I don't see a quick fix for that while keeping stderr,
and the stderr output is fairly useful.
Output "ViewIndex" into the pixel shader hits array
Select the pixel shader input which matches the viewIndex to the passed in view
Ignore the view parameter if set to ~0U (rd.ReplayController.NoPreference)
Ignore the view parameter if any subpass has empty multiviews
DebugShaderInputs struct contains existing the parameters:
sample
primitive
and a new parameter
view
Default constructor for DebugShaderInputs sets the parameters to NoPreference (~0U).
* The compiler could compile an entry point "foo" into an export "bar". We use
the exported name in most places as that's guaranteed to be unique by the API
and used for cross-referencing, but when recompiling we pass the original
source name as in the debug info.
baldurk