* 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>
When enabling the Vulkan validation layers, the 'validationLayerName'
variable technically went out of scope before vkCreateInstance() was
called. While most compilers won't clean up stack variables after random
'if' statements, some will, particularly when optimisation or memory
sanitizers are enabled.
This can lead to vkCreateInstance() segfaulting when
SDL_HINT_RENDER_VULKAN_DEBUG is enabled.
Instead, make the validationLayerName visible throughout the entire
VULKAN_CreateDeviceResources() function.
While we're at it, extract the validation layer name out into a
preprocessor #define, so that we are definitely using the same name in
VULKAN_ValidationLayersFound().
Signed-off-by: David Gow <david@ingeniumdigital.com>
This pull request adds an implementation of a Vulkan Render backend to SDL. I have so far tested this primarily on Windows, but also smoke tested on Linux and macOS (MoltenVK). I have not tried it yet on Android, but it should be usable there as well (sans any bugs I missed). This began as a port of the SDL Direct3D12 Renderer, which is the closest thing to Vulkan as existed in the SDL codebase. The shaders are more or less identical (with the only differences being in descriptor bindings vs root descriptors). The shaders are built using the HLSL frontend of glslang.
Everything in the code is pure Vulkan 1.0 (no extensions), with the exception of HDR support which requires the Vulkan instance extension `VK_EXT_swapchain_colorspace`. The code could have been simplified considerably if I used dynamic rendering, push descriptors, extended dynamic state, and other modern Vulkan-isms, but I felt it was more important to make the code as vanilla Vulkan as possible so that it would run on any Vulkan implementation.
The main differences with the Direct3D12 renderer are:
* Having to manage renderpasses for performing clears. There is likely some optimization that would still remain for more efficient use of TBDR hardware where there might be some unnecessary load/stores, but it does attempt to do clears using renderpasses.
* Constant buffer data couldn't be directly updated in the command buffer since I didn't want to rely on push descriptors, so there is a persistently mapped buffer with increasing offset per swapchain image where CB data gets written.
* Many more resources are dependent on the swapchain resizing due to i.e. Vulkan requiring the VkFramebuffer to reference the VkImageView of the swapchain, so there is a bit more code around handling that than was necessary in D3D12.
* For NV12/NV21 textures, rather than there being plane data in the texture itself, the UV data is placed in a separate `VkImage`/`VkImageView`.
I've verified that `testcolorspace` works with both sRGB and HDR linear. I've tested `testoverlay` works with the various YUV/NV12/NV21 formats. I've tested `testsprite`. I've checked that window resizing and swapchain out-of-date handling when minimizing are working. I've run through `testautomation` with the render tests. I also have run several of the tests with Vulkan validation and synchronization validation. Surely I will have missed some things, but I think it's in a good state to be merged and build out from here.
This better reflects how HDR content is actually used, e.g. most content is in the SDR range, with specular highlights and bright details beyond the SDR range, in the HDR headroom.
This more closely matches how HDR is handled on Apple platforms, as EDR.
This also greatly simplifies application code which no longer has to think about color scaling. SDR content is rendered at the appropriate brightness automatically, and HDR content is scaled to the correct range for the display HDR headroom.
This does something a little weird, in that it doesn't care what
`__ANDROID_API__` is set to, but will attempt to dlopen the system
libraries, like we do for many other platform-specific pieces of SDL.
This allows us to a) not bump the minimum required Android version, which is
extremely ancient but otherwise still working, doing the right thing on old
and new hardware in the field, and b) not require the app to link against
more libraries than it previously did before the feature was available.
The downside is that it's a little messy, but it's okay for now, I think.
- Simplified public API, simplified backend interface.
- Camera device hotplug events.
- Thread code is split up so it backends that provide own threads can use it.
- Added "dummy" backend.
Note that CoreMedia (Apple) and Android backends need to be updated, as does
the testcamera app (testcameraminimal works).
This makes the existing SDL_SoftStretch code work with them, at least for
nearest-neighbor scaling; otherwise, it'll mangle the data trying to scale
it as 8bpp data without warning.
It is becoming necessary to enable additional features as libdecor continues to evolve, and checking against a single base version will no longer be adequate. Libdecor doesn't provide versioning defines in its headers, so split the version string into parts to allow for discrete version detection and feature enablement at build time.
__builtin_memcpy, as well as __builtin_memset and __builtin_memmove, needn't be
inlined but emitted as a libc call, leading to infinitely recursive calls.
Fixes https://github.com/libsdl-org/SDL/issues/9090
This refers to the HID Simple Haptics spec, which is currently only implemented by the Surface Dial accessory and WMR game controllers, which aren't currently exposed by the GameInput API.
We can add support for other effects in the future, but for now we don't need this or the SDL_gameinputjoystick_c.h header.
Joystick drivers are sorted by priority in the driver list, and higher priority drivers report whether they are handling a device when lower priority drivers want to add it to their device list.
This has been handled ad-hoc with the Windows and HIDAPI drivers, but this formalizes the idea and makes sure that GameInput has the highest priority of the Windows drivers.
- Move legacy name choice to a separate function, so we can `return` a
string in one line instead of assign a variable and `break` for each item.
- Have the case statement cover SDL_NUM_SYSTEM_CURSORS, and not `default`, so
compiler will (maybe) warn us if an enum value is added but not included
here.
- Only choose a legacy name if necessary.
(cherry picked from commit df00a7dd4c3deb03839e799187a3c75fc4e8854b)
As suggested in #8939.
This results in some minor changes for emscripten and x11. Both
previously mapped SIZEALL to "move", but "move" is not guaranteed to be
a four-pointed arrow: according to the CSS spec, it's actually intended
to be a drag-and-drop cursor, analogous to "alias" and "copy".
Map it to "all-scroll" instead, as in Wayland: while this is *also* not
semantically guaranteed to be a four-pointed arrow, it is at least
*suggested* to make it a four-pointed arrow.
Also, emscripten was previously using two-pointed arrows for resizing
(BOTTOMLEFT mapped to "nesw-resize", and so on). This commit changes
it to use the more specific "sw-resize" and so on, which might be
single-directional.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The "left_ptr" name is an X11 thing, and there's no guarantee that
Wayland cursor themes contain it. In particular, GNOME's Adwaita theme
as of version 46.beta only contains the CSS/freedesktop names.
To test, either move one of the known cursors out of the way, or edit
the switch statement above to use a wrong name for one of them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The freedesktop.org cursor spec recommends the same names as CSS, and
GNOME is treating the CSS vocabulary as canonical.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Apparently this is necessary on the latest Gnome to get properly themed
cursors, vs ancient X11 standard cursors, as Gnome has dropped the old
theme names that XCreateFontCursor eventually expected to find.
Fixes#8939.
This catches the case where we obtain a logical device while the default is
changing in another thread, so you accidentally end up with the previous
default physical device locked and returned from ObtainLogicalAudioDevice.
Zeroing the window width and height was necessary in SDL2 to short-circuit the resize event deduplication code when the window backing scale changed, but not the logical size. This is no longer necessary in SDL3, as it will explicitly check for scale changes on resize events and dispatch pixel size/scale changed events as appropriate, even if the window's logical size hasn't changed.
Windowing systems that receive fullscreen state changes asynchronously may not receive a configure event notifying SDL that the window has left fullscreen when the window is being destroyed. Ensure that no display holds a reference to a destroyed fullscreen window.
Renamed the following property define names to have a type suffix to
match other property names.
SDL_PROP_TEXTURE_OPENGL_TEXTURE_TARGET (number)
SDL_PROP_TEXTURE_OPENGLES2_TEXTURE_TARGET (number)
SDL_PROP_WINDOW_CREATE_WAYLAND_SCALE_TO_DISPLAY (boolean)
SDL_PROP_WINDOW_RENDERER (pointer)
SDL_PROP_WINDOW_TEXTUREDATA (pointer)
Sam Lantinga
Dan Ginsburg
Frank Praznik
Anonymous Maarten
danginsburg
Ryan C. Gordon
David Gow
Ozkan Sezer
Mathieu Eyraud
Robert Edmonds
Nikita Krapivin
Simon McVittie
Zack Middleton
Hans-Kristian Arntzen
Chris Collins