If the buffer size is less than (vertexCount * stride), the last vertex
may be considered out-of-bounds, even if all attributes are included in
the vertex.
Fixes#2131.
The stride may not give us the full picture here as the stride
may not encompass the vertex declaration entirely.
Consider a vertex declaration of size 20, and a stride of 12,
we may not have covered the whole range of space the draw wants with
VertexCount * Stride.
Some games such as FF13 Lightning Returns have two float3s in the vertex decl
and draw two triangles with the last float being out of bounds. This causes
the whole vertex element to be set to 0 on NVIDIA which breaks their fullscreen passes.
Instead, take (VertexCount - 1) * Stride + VertexDeclSize for the buffer size
and pad with 0s outside of the VertexCount * Stride range.
Closes: #2046Closes: #1908
This is an invalid optimization and leads to render hazards being dropped
Our hazard tracking for render targets is done in render target indices as opposed to texture indices for depth stencil tracking so `texMask` doesn't work for that reason, and the fact that even if it did, there is no relationship to an individual texture and a render target index that has a hazard.
Track depth stencil textures being used and whether we have any active hazards.
Rebind the framebuffer with VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL if we encounter a depth stencil hazard.
Fixes black squares in Mass Effect and validation errors in some titles.
Closes#1484
I am naive to think that this API is in any way sane, and that iSwapChains actually does what you would expect.
Swapchains created by CreateAdditionalSwapchain[Ex] are not tracked in that figure... There can only ever be one.
Great API. Very cool.
This also adds and consolidates some missing thread synchronization on the swapchain functions (that should have already had it).
(note: m_implicitSwapchain always exists, so we don't need to lock if that's all we call.)
