The spec for `vkMapMemory` requires that `size` must be greater than 0.
However, `vkFlushMappedMemoryRanges` may include `VkMappedMemoryRange`s
with `size` equal to 0.
RenderDoc replays `vkFlushMappedMemoryRanges` by calling`vkMapMemory`,
copying the data, and then calling `vkUnmapMemory`. This can turn valid
`vkFlushMappedMemoryRanges` into invalid `vkMapMemory` calls.
This fix skips the `vkMapMemory` (and corresponding `vkUnmapMemory`
calls) for zero size ranges.
Change-Id: I08fd40f36f2c63e28f3df42bc799981b5eb35295
The code to get initial values for PS debugging includes a step to
traverse the shader stage's inputs and previous stage's outputs, to
define a struct that is used in a replacement pixel shader to collect
the initial values. This logic is API-agnostic and can be moved to a
DXBC file to allow D3D12 to use it.
* We assume that fxc won't output a denormalised float in the bytecode, and this
prevents us from flushing integer inputs to otherwise flushable float-type
operations
* Instead of tracking their lifetime with that object, we move the lifetime
tracking into the parent VulkanGraphicsTest and destroy them all at the end. A
single handle can optionally be free'd on its own.
* Previously we had "Frame X" and "Start of Frame" hardcoded in the event
browser, and the end of frame was in many cases assumed to be a present call.
However with the in-application API this is not necessarily true.
* Presents are now serialised separately in all APIs and displayed wherever they
happen in the frame, and if there is no present at the end of the frame an
"End of Capture" marker is inserted. Similarly API-defined captures are not
given a potentially misleading frame number.
* The initial states for GL programs contain a uniform mapping table, which is
required for correct replay. We already do this in glLinkProgram we were just
missing the call in glCreateShaderProgramv.
For images with both depth and stencil aspects, `VkImageMemoryBarrier`s
must include both depth and stencil aspects--e.g. you cannot transition
the layout of the depth alone. This can be violated by the barriers in
RenderDoc replay that transition image layouts before and after
initialization. This change ensures that, if depth or stencil needs to
be initialized, then beth will be initialized, and the image layout
transition will be applied to the two aspects together.
Specifically, `ImgRefs` stores a separate FrameRefType for each aspect.
This can cause the depth and stencil aspects to have different reset
requirements, which can cause a barrier to contain only one of the
depth/stencil aspects.
Change-Id: I8a16a0c450bd8e6cb0d60c1d688b01b75df86915
Apply_InitialState transitions the image layouts to TRANSFER_DST_OPTIMAL
before copying/filling the image initial contents. However, the
`oldLayout` for these transitions was set incorrectly--in particular,
before the first replay, the image is in the UNDEFINED layout, but is
transitioned from whatever layout it is in at the end of the capture.
In fact, it is safe to always set the `oldLayout` to UNDEFINED, since
these barriers immediately precede a write.
This change introduced some additional assymetry between the barriers
before/after the write, which required `ImageInitializationBarriers` to
produce both sets of barriers (before/after write), rather than just
reversing the barriers.
Change-Id: Ica6fdaafb2442192691f9ed853cfce094bf2da4f
* Instead of the buffer/source texture tracking all the views of itself and
checking to see if it should be force-included because any of its views were
included, we instead track the underlying resource for each view or buffer
texture.
* This means if e.g. a view or buffer texture gets dirtied, we can propagate
that through to the underlying data store which needs to get dirtied so that
we can fetch its initial states.
baldurk