* We can't emulate true separate shader objects, but we can emulate
glProgramUniform* which we use often, and silently drop attempts to make
programs separable. Then as long as elsewhere we can avoid actually relying on
separable programs.
* This will need to be used in combination with ARB_program_interface_query
emulation, but it's unlikely that that extension is available but
ARB_separate_shader_objects isn't.
`vkCmdFillBuffer` and `vkCmdUpdateBuffer` each replace the contents of the
buffer in the specified interval, so this should be treated as a CompleteWrite.
* This is most commonly caused by the application deleting a buffer bound to a
VAO and then drawing with the VAO. For unknown wild reasons this is actually
valid according to the GL spec but actually handling it correctly is
prohibitively expensive and not worth it.
* We cache the expensive check for draw validity while loading to reduce the
cost of this per-draw detection.
This commit adds the GL_TEXTURE_COMPARE_MODE parameter to the
TextureSamplerState struct, and sets its value to GL_NONE in
SetSamplerState. This fixes the issue of depth textures that use
GL_COMPARE_REF_TO_TEXTURE being displayed as solid black or white
in the texture viewer.
* We'll have to add fallbacks for most of the functionality that's not
available, and there's no point letting users know they're running on a
degraded GL implementation since it can't be fixed with an upgraded driver.
* This means if we're launching a system copy of adb, we don't have a dangling
process holding a reference to our folder. Mostly relevant during development
when we might want to clear the build but adb is running keeping the folder
alive.
* 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.
baldurk