Previously, the ref type of the a VkDeviceMemory or VkImage resource
was calculated as the max of the ref types of the subresources. This
reliance on the ordering of the `FrameRefType` enum values is fragile--
in particular, this makes it more difficult to add new `FrameRefType`
alternatives.
Now, the ref type of composite resources are calculated using
`ComposeFrameRefsDisjoint` instead of `max`.
Change-Id: Id5db68b6756555cdc6b068d28f1b72cb827f3d1e
* GLES doesn't support ARB_occlusion_query2 at all, and ARB_timer_query (or
equivalent) may not be available for durations.
* Check for ARB_query_buffer_object before pushing or popping query buffer
binding.
* Technically if you create a context with *CreateContextAttribsARB and don't
specify a profile mask at all, the spec says the value of the profile bit is
CORE_PROFILE_BIT. In practice this means drivers may or may not give you a
core or compatibility profile.
* However what we're really looking for here is the chance that the user code
will use only modern GL or will use deprecated functionality, and in that case
the high likelihood is if they omit the PROFILE_BIT entirely they are probably
unaware of it, rather than letting it set its default value.
* If a buffer has been marked as dirty mid-frame but wasn't dirty at the start
of the frame then it won't have initial contents. We have to treat it as if it
wasn't dirty and fall back to using our existing data for it, assuming that is
a valid way to pre-populate the map's shadow buffer.
* It's theoretically possible to have a bash shell without awk or sed available
(though very strange), so we can use cmake string processing & configure_file
to get the same effect.
* This typically means that the user hasn't checked correctly for SM6 feature
support before trying to upload DXIL shader, which will then result in
unpredictable behaviour or crashes on replay.
* During capture we detect this and flag it in the overlay text, and prevent
capturing. On capture load we fail to load if we detect such a PSO.
This changes the behaviour of Apply_InitialState for images with
BufferCopy type InitialState. Previously, the entire image was
transitioned to DST_OPTIMAL, along with a possible queue family
ownership transfer. Now, only the image subresources that are actually
copied/cleared are transitioned.
Change-Id: I92ab4d7160e99b81222231d1d974e707a55f7aef
This uses the new image tracking to avoid unnecessary copying of image
data when applying the initial state.
This change only affects image resets when all of the following apply:
- The image initial contents tag is `BufferCopy` (not
`ClearColorImage` or `ClearDepthStencilImage`),
- The image is single sample,
- The image is non-sparse,
- The image has `ImgRefs` data,
- The image has been completely initialized at least once, and
- VulkanResourceManager::OptimizeInitialState() is true (currently
disabled by default).
When all of these conditions are met, data will only be copied for those
image subresources which require reset according to the ImgRefs data.
Change-Id: I449eabfe969229fa64e233760aaadb489776ee23
* These features aren't supported by the underlying implementation.
* Triangle size we can feature-detect properly - by checking for geometry shader
support. Quad resolve should be supported but metal doesn't allow atomics on
images so we have to check specifically for a metal backend.
* This is necessary for e.g. the cube demo where it can create the image as
LINEAR in HOST_VISIBLE memory and then the image never gets dirtied, so we
don't properly create initial contents for it - instead only fetching the
underlying memory which is not technically legal.
Benson Joeris