Platform review #6570
Comments
|
os/2 can go. that pandora config and makefile can go. several audio backends such as esd, nas, arts can go. |
|
For Windows audio we can technically remove every backend that isn't WASAPI, but at the same time I feel like we're going to be fighting OS bugs in WASAPI until the end of time... would be good to figure out if there's something we can do at the API level to finally fix it for good. |
|
That visualtest thing can go too: no one maintained it, ever.. |
|
I'm adding things to the checklist above, feel free to say something if you disagree. @sezero, once everyone has a chance to chime in, feel free to nuke each one as a separate commit. |
Literally did not expect Ozkan to say this. :)
Winmm can be retired for sure, but having DirectSound as a foil has been useful, even if it's just to demonstrate something is wrong with our WASAPI code. But, legit question: we're dropping WinXP support, right? Where should we cut on this? |
|
arts, esd and nas can all go. Also fusionsound, nacl, paudio, qsa, possibly sndio if OpenBSD isn't still using it, possibly sunaudio if Solaris isn't still using it (or if no one is using Solaris). QNX support can go; we don't have any way to maintain it and it has a proprietary SDK we no longer have a license for. If it becomes a going concern or someone steps forward to maintain it, we can resurrect it from revision control. |
|
(Sorry for all the spam here) If dsp can go along with all the other legacy Unix backends, we can remove the higher level code for manage Unix /dev/dsp devices that is in src/audio itself. If all the network sound servers and all the random device name backends are going, we can remove the idea that there might be arbitrarily-named audio devices in SDL3. (and even if not, we should just make forcing an arbitrary device name/server address a hint that affects the outcome of opening the default SDL device). |
|
Also, this might be too aggressive, but I'd consider deleting PSP, Vita, PS2, and Nintendo 3DS support up front, and let them live in SDL2, and add them back to SDL3 if they want to maintain them once we've ripped everything up. Obviously the Stadia fork is not migrating to SDL3. The other private forks will, I assume. Do we need "android", "aaudio" and "opensles" audio targets? What is Android using at this point? Can "jack" audio go away now that pipewire is the new hotness? Did NetBSD ever pick up ALSA or PulseAudio, or do they really still need a bespoke /dev interface? |
|
We're probably stuck with jack but only for the same reasons as pulse, both could probably be deprecated by the time 3.0 is done and be removed toward the end of 3.x's lifecycle. |
|
The "raspberry" video driver can go (modern Raspberry Pi OS supports kmsdrm on at least the Pi 3 and Pi 4, if not others). I think we delete the DirectFB code, which I am not convinced ever worked in SDL2. What is "vivante"? Is this still used? How about riscos? In joysticks, if "iphoneos" is still used, let's rename that to ios. In render, can we dump Direct3D 9? OpenGLES 1? (Direct3D 12 and Metal should be obsoleted by the GPU work eventually, GLES2 might need to hand around for what qualifies as a lower-end device in current times). |
In my opinion we can drop WinXP and Vista, but we should keep 7 and 8. Together they are a little more than 4% of the October 2022 Steam hardware survey, and 4% of millions of players is quite a few. :) |
There will always be arbitrarily named audio devices. :) |
kmsdrm still doesn't perform as well as the vc code in older Raspberry Pi OSes, and the Steam Link app still needs to support it, as they are still the best direct replacement for Steam Link hardware.
We still have random folks working on embedded systems that use DirectFB - it was their only alternative once we removed fbcon support. I think most embedded systems now have capable GLES2 stacks, so our dummy driver with offscreen GLES may be a viable replacement these days.
Yes, Steam Link hardware, still supported by Valve. ;)
We've gotten some recent commits for this, we should reach out to the author and get their opinion.
Not only is it still used, it's the recommended path going forward for macOS. It definitely needs to be renamed though.
OpenGLES 1 can go. Direct3D 9 is still the best video decode path on a lot of video cards, so Steam Remote Play defaults to using that. |
|
What about Haiku? |
|
WinRT can be cut, all our use cases should now fall under GDK. The Xbox Creator Program is UWP's last exclusive customer and ID@Xbox is far preferable for shipping software on Xbox. |
|
Haiku is still in active development, I'm inclined to keep it for now. |
Honestly I'd sort of like to replace it with an fbcon target that can only handle a window framebuffer, or if it's feasible, add a window framebuffer that doesn't require OpenGL to the kmsdrm target. Just really want to find a way to eject the creaky old dependency here that'll work for these embedded people. |
This seems like a good option, and there's already a request for it in #6561 |
Well, why not. Obviously I'm not experienced enough to keep supporting and |
Seconded |
It might be wise to still keeping it, at least for some time? Isn't that still the |
I'd definitely want something other than WASAPI to be around for a bit longer — WASAPI has been broken too often recently in "interesting" setups (weird sample rates / running under wine / etc). So having either winmm or DirectSound would be worth keeping. Also, I'm still shipping a few things which need Windows XP support, though they easily can stay on SDL2. (Not to say it wouldn't be nice to avoid going out of our way to break support for older OSes where it doesn't gain us anything.) More generally, do we need to work out what a "minimum hardware spec" for different parts of the API are? |
Agreed, about time to focus mainly on shader capable renderers. PSP, Vita, PS2 and Nintendo 3DS can live inside SDL2 branch. |
I'm still interested in maintaining this, and would be keen to see it continue to be supported in SDL3.
If we're keeping RISC OS support, then we'll need to keep this as well.
I was under the impression that the plan was to continue to support at least the Render API alongside the new GPU API, so SDL3 would in theory still be at capable of supporting the same platforms that SDL2 does. Is there anything planned that would require a major rework of the audio or video drivers? |
We're not talking about dropping things because the tech is moving on, we're talking about dropping things no one is using. We don't have specific plans yet, but both the audio and video internal interfaces had dramatic changes between 1.2 and 2.0...basically all the existing targets got rewritten to support this. It might not be as dramatic for SDL3, but we don't know yet. Also, major releases are a good time to trim out abandoned platforms. We did this for SDL2, as well, as things like MacOS Classic and Windows CE got ripped out. And, over time, some drifted in, like OS/2...it mostly matters if someone shows up to do the work. For example, if you like RISC OS and are willing to make sure it works occasionally, I don't mind if it stays. |
|
Yes, we plan to continue 2D platform support - for example we're talking about adding a software KMSDRM path. It obviously won't support the new GPU API, but that's not a requirement for SDL support, it's an optional feature for modern hardware. The goal is to make sure that SDL 3 has a cleaned up API, and is supporting what people are actually using. |
|
SysWM can drop support for Mir, as it's long since been abandoned/defunct and the backend video driver for it was deleted years ago. |
Done. |
|
Probably worth doing a cleanup pass of the Wayland stuff for the same reason - off the top of my head we can probably clean up a ton of stuff in SysWM (i.e. old wl_shell junk) and there's probably more we can trim or clean up from the implementation as well. |
@sezero, can you put jack back? |
Done. Should we make it default to disabled, or still keep it enabled? |
Removed now. |
It would be good to keep the ability for applications to create OpenGL ES 1 contexts using SDL3, even if it's not used by the Render API. Alternatively, it might be worth splitting the opengl renderer into two renderers, one for shader-based rendering (+ GLES 2), and one for fixed-function rendering (+ GLES 1). That way, it would both be easier to continue supporting all OpenGL versions, and would avoid the need to duplicate code when adding new shader-based functionality. |
Let's leave it enabled. |
I don't think there's any plan to remove OpenGL ES 1 context support from the video code, but it's getting hard to verify that we haven't broken anything when looking at fixed function OpenGL vs core OpenGL with EGL vs GLX/GLW. Splitting the renderers is what we had already done with the separate opengl, opengles, opengles2 render backends, and we just deleted opengles (1.0). Are you talking conceptually here, or do you have specific use cases that you can use to verify functionality? |
|
@sezero, the intent was just to remove the opengles 2D renderer, not completely remove GLES 1 support. And thinking about it, let's hold off on removing the renderer too, for the moment. Can you back out your opengles changes? Thanks! |
|
Reverted opengles removal now. |
Thanks! |
|
We need to do a little more research before we pull the trigger on WinRT removal, so I added it back temporarily in a635a48. |
|
Yeah, as far as I could tell FNA was the last user of UWP, and we've made it pretty clear that it's unsupported: https://github.com/FNA-XNA/FNA/wiki/Appendix-F:-Upcoming-Support-Changes#uwp-support |
|
It's being used for Hololens development, apparently. I'm not permanently bringing it back, I just wanted to make sure that nobody needs it before it gets nuked, while it was still easy to revert. |
To follow-up on this (and something that was said earlier): While it's true that the "Windows Store no longer requires UWP", it does not mean that "you can use GDK on PC" in all of the same circumstances. The base license terms for the GDK may be incompatible with certain situations (or other licenses) that are used with apps using UWP today. Additionally:
(Source: https://github.com/microsoft/GDK/blob/Main/README.MD) So from that standpoint, there can exist applications that may currently be able to use UWP, but that may not be able to use the GDK (due to licensing constraints / conflicts). |
And they can always use SDL2, can they not? |
Certainly - I just bring it up as a data-point. (Given past headaches due to projects stuck on SDL1, not able to benefit from the numerous improvements and fixes in SDL2.) To clarify: I'm not commenting on whether it's worth keeping the UWP platform support, given the (apparent) deprecation status and likely lack of maintainers on this end. Just that it's not always a drop-in UWP -> GDK replacement. (At least, currently. GDK licensing could theoretically change again in the future.) |
In any case, a platform support should have at least one active maintainer, where, with the WinRT case, no one seems to have volunteered. (see e.g. #5842.) |
|
RetroArch is still riding the UWP horse, and so is the few UWP emulators that still exist. It's pretty clear that we will be dealing with UWP as long as it still exists as a game and emulator development platform and as long as they don't officially shut down the program or actually give us another viable method to develop games for Xbox without the chance of running into troubles with NDAs and license conflicts. |
|
I am able to build and test UWP code here, so in a pinch I can look at UWP issues on Windows. Given that people are actively developing and publishing with it, let's leave it as a viable SDL3 platform. |
|
The OpenGL ES 1.0 2D renderer has been removed. |
Vita renderer is shader-capable (you actually can't render anything at all without shaders) |
|
About WinMM: there is a case at my buddies where they had ASUS Xonar sound cards and running Windows 10, the WASAPI just sucks (inconsistent volume levels, etc. That happens at their machine only, doesn't happen at others), and using DirectSound while works, it has another bug: when ANY DirectSound application client gets crashed or killed, last played audio buffer chunk will remain sound permanently and no way to get it rid without the whole reboot of the computer. So, WinMM is a saviour from that freaking bug. Also, certain users reported to me that DirectSound doesn't work at all on their machines (I don't remind which OS, possibly Windows 8 or 8.1), but WinMM worked just fine. So, I vote we should keep WinMM too as a fallback, even for modern Windows. |
|
I was about to submit a small fix for the QNX audio plugin when I noticed that support was removed. Can it be brought back? Last time I made a fix QNX contributed a licence to the SDL project so it can at least be built. If the licence expired I'm sure we can get a new one. |
Doable. I have began experimenting with this as a peer requested such functionality, but went with a different route afterwards. You can find said proof of concept here. I also developed a drm+dumbbuffer backend for SDL1.2 with the folks at the OpenDingux distro which is a whole lot more mature and feature complete. Don't treat this as a PR proposal, only posting it for reference. The code is known to have problems such as:
If this is interesting to anyone, it should be fairly straightforward to pick it up from here. In such case, feel free to ping me at the SDL discord if necessary. EDIT:: Maybe this is something a future version of SDL could provide? |
We removed it because no one was available to maintain it (and we likely can't add it to GitHub Actions without publishing a private license key, even if we still had one that worked). That being said, I'm 100% okay with putting QNX back in if someone checks in on the code from time to time. |
|
So there's still some desire for the GLES1 renderer...the concern isn't so much older hardware, but that it happens to work across a lot of platforms (and, in rtrussell's case, he wants to call GLES1's glLogicOp() directly, which was dropped in GLES2). This is in regards to this thread: https://discourse.libsdl.org/t/with-the-new-sdl3-will-be-sdl2-abandoned/41322 I'm not against finding some way to supply this that doesn't include having it in SDL3, like we did with the gesture stuff...in this specific case, they're using the SDL2 renderer API but require it to use GLES1 under the hood, so it's not a question of API compatibility, which is to say if there's a reasonable way to split it out, it doesn't really matter that they would lose access to Direct3D, Metal, GLES2, etc, because they wanted to avoid those anyhow. At least, that's my understanding. I don't have a plan at the moment, and the easiest thing to do is just re-add the GLES1 renderer and be done with it, but I'd like to solve this for rtrussell in some form or another. |
|
I can certainly volunteer to maintain the QNX port, as I use SDL extensively to test the sanity of kernel changes. I was about to post a pull request to bring back the QNX code, but then noticed the change from autotools to cmake, which is going to require some work. I can't promise when I'll have something ready, but it's good to know the project is open to accepting the code. |
|
I'll go ahead and close this. It seems like, except for QNX support which may come back, this is a good list of platforms to clean up for SDL3. |
Review the set of supported platforms. Are there any that we should remove due to lack of active maintainer?
Platforms:
Audio subsystems:
(dsp is still used by RISC OS, per Platform review #6570 (comment))
Video subsystems:
Misc:
@libsdl-org/a-team
The text was updated successfully, but these errors were encountered: