When the color write enable state (from VK_EXT_color_write_enable) is
not dynamic (i.e the extension is not used),
VulkanRenderState::colorWriteEnable was initialized from pipeline's
color mask info. However, this information should be ignored if color
write mask is dynamic (with shader object / EDS3).
Instead, if color write enable state is not dynamic, it can be
implicitly considered to be true if VkPipelineColorWriteCreateInfoEXT is
not provided, or otherwise it's taken from that.
This change fixes the UI (and HTML export) where the color mask was
output as `____` in such situations regardless of what mask was
dynamically set.
- add secondary commands buffers to Submit() calls so they get put back into the command buffer pool
- fix validation error about renderEndSemaphore
- fix sync validation errors
- add more names to objects
- fix some incorrect names
- move the pipeline bind to after marker "DrawIndirect: Single"
- add marker to start and end of EIDS which should be tracked for resource usage
- add a per frame update descriptorset
- bind compute descriptor sets before binding compute pipelines
- Remove hard coded EIDs from VK_Resource_Usage python
* Some CaptureAccess uses like enumerating GPUs happen before the replay thread
is running, in this case we can safely run on the UI thread as we know there
will be nothing to conflict with.
* We previously decided we'd normally access this only on the UI thread when
local, and only on the replay thread when remote (by neccessity), but some
actions like resolving symbols can be quite slow so we want to make sure these
are actually async and so we leave them on the replay thread so we can display
a proper UI spinner and leave the UI thread active.
* We always just hold one version of the bytecode, in the shader container
(possibly with an extra debug blob on D3D where that is necessary for DXBC).
* We also remove any attempt to fall back to the original shader blob if we have
debug search paths found and we get a debug replacement blob (mostly relevant
for Vulkan but legacy separate debug info on DXBC also does whole-blob
replacement). If the debug search paths change and we reload, but fail to find
a debug blob, we continue using the previous debug blob if we had one.
* Unclear why this was blocked on OS X clang as it clearly fires, but this means
this warning is no longer OS X only which makes iterating on normal machines easier.
Shahbaz Youssefi