- Always use internal qsort and bsearch implementation.
- add "_r" reentrant versions.
The reasons for always using the internal versions is that the C runtime
versions' callbacks are not mark STDCALL, so we would have add bridge
functions for them anyhow, The C runtime qsort_r/qsort_s have different
orders of arguments on different platforms, and most importantly: qsort()
isn't a stable sort, and isn't guaranteed to give the same ordering for
two objects marked as equal by the callback...as such, Visual Studio and
glibc can give different sort results for the same data set...in this
sense, having one piece of code shared on all platforms makes sense here,
for reliabillity.
bsearch does not have a standard _r version at all, and suffers from the
same SDLCALL concern. Since the code is simple and we would have to work
around the C runtime, it's easier to just go with the built-in function
and remove all the CMake C runtime tests.
Fixes#9159.
* Make sure to always write pointSize in VS (fixes validation error in testsprite)
* Fix validation error from acquiring swapchain semaphore more than once
* Fix validation error from using incorrect framebuffer size in testautomation
Now passes testautomation with validation.
* Vulkan Renderer - implement YcBcCr using VK_KHR_sampler_ycbcr_conversion. This simplifies the shader code and will also allow support for additional formats that we don't yet support (such as SDL_PIXELFORMAT_P010 for ffmpeg). The renderer now queries for VK_KHR_sampler_ycbcr_conversion and dependent extensions and will enable it if it's present. It reimplements YUV/NV12 texture support using this extension (these formats are no longer supported if the extension is not present). For each YUV/NV12 texture, a VkSamplerYcbcrConversion object is created from SDL_Colorspace parameters. This is passed to the VkImageView and also an additional sampler is created for Ycbcr. Instead of using 1-3 textures, the shaders now all use 1 texture with a combined image sampler (required by the extension). Further, when using Ycbcr, a separate descriptor set layout is baked with the Ycbcr sampler as an immutable sampler. The code to copy the images now copies to the individual image planes. The swizzling between formats is handled in the VkSamplerYcbcrConversion object.
The removal of a wl_output may not be accompanied by leave events for the surfaces present on it. Ensure that no window continues to hold a reference to a removed output.
The VULKAN_InvalidateCachedState() function seems to be meant to
invalidate any _cached_ state, i.e. global state of the API which may
have been modified outside the renderer.
However, at the moment, the Vulkan renderer also resets a number of
internal variables which track buffers, offsets, etc, in use. As a
result, the renderer can get into an inconsistant state and/or lose
data.
For example, if VULKAN_InvalidateCachedState() is called in between two
calls to VULKAN_UpdateVertexBuffer(), the data from the first call will
be overwritten by that from the second, as the number of the next vertex
buffer to use will be reset to 0. This can result in rendering errors,
as the same vertex data is used incorrectly for several calls.
By no longer resetting this 'internal' state here, those glitches
disappear. However, I haven't tested this with any applications which
mix the Vulkan renderer with their own Vulkan code (do any such
applications exist?), so this may be insufficient in case a full flush
of the renderer state -- and possibly a wait on the appropriate fence
-- could be required.
Signed-off-by: David Gow <david@ingeniumdigital.com>
When selecting a memory type, there are some property flags we need
(e.g., VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, without which we cannot
vkMapMemory), and others we'd simply prefer (e.g.,
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, which may have a performance
impact, but otherwise shouldn't be required).
By specifying these separately, we can fall back to a memory type which
doesn't have everything we want, but which should still work, rather
than giving up.
Signed-off-by: David Gow <david@ingeniumdigital.com>
VULKAN_FindMemoryTypeIndex() tries first to get a perfectly matching
memory type, then falls back to selecting any memory type which overlaps
with the requested flags.
However, some of the flags requested are actually required, so if -- for
example -- we request a memory type with
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, but get one without it, all future
calls to vkMapMemory() will fail with:
```
vkMapMemory(): Mapping memory without VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set. Memory has type 0 which has properties VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT. The Vulkan spec states:
memory must have been created with a memory type that reports VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT.
```
(This occurs, for instance, on the totally non-conformant hasvk driver
for Intel Haswell integrated GPUs, which otherwise works fine.)
Instead, make sure that any memory type found has a superset of the
requested flags, so it'll always be appropriate.
Of course, this makes it _less_ likely for a memory type to be found, so
it does make #9130 worse in some ways. See the next patch for details.
Signed-off-by: David Gow <david@ingeniumdigital.com>
Sam Lantinga
danginsburg
Ryan C. Gordon
SDL Wiki Bot
Dan Ginsburg
Frank Praznik
Anonymous Maarten
Semphriss
David Gow