* We don't really need to update the version, any VC 2015 version would do, and
it causes the installer to try to trigger a reboot if the CRT is in use, which
is quite likely.
This change reduces the amount of data copied into VkDeviceMemory resources in
`Apply_InitialState`; this uses the new (interval-based) reference tracking.
On a large capture from a recent game, this change reduces the amount of copied
data from 2.2GB to 720MB (plus 100MB cleared to 0). This reduces the time spent
in `ApplyInitialContents` from 1800ms to 1500ms.
Ranges of memory are initialized/reset by either clearing to 0, or copying in
the initial state data, according to the `FrameRefType`, as follows:
- Read-only (`eFrameRef_Read`) regions of memory are initialized by copying
once, before the first replay.
- Read-before-write (`eFrameRef_ReadBeforeWrite`) regions of memory are reset by
copying before each replay.
- Write-only (`eFrameRef_PartialWrite` and `eFrameRef_CompleteWrite`) regions of
memory are cleared to 0 before each replay. This is intended to avoid possible
user confusion when inspecting these regions of memory, as they might
otherwise show data written later in the frame.
- Unused (`eFrameRef_None`) regions of memory are cleared to 0 once, before the
first replay.
Attachments might be read and/or written. Pessimistically assume attachments are
read and then overwritten. Further analysis should be able to refine this access
type in some cases.
* We now push everything mutable about the draw data configuration into a single
struct which we copy around (the actual buffer data remains refcounted and not
copied). This means that we don't have one thread still trying to do things on
a model which is being updated on another thread.
* 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
baldurk