search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
10k stars 1.85k forks source link

Platform review #6570

Closed slouken closed 1 year ago

slouken commented 1 year ago

Review the set of supported platforms. Are there any that we should remove due to lack of active maintainer?

Platforms:

Audio subsystems:

Video subsystems:

Misc:

@libsdl-org/a-team

sezero commented 1 year ago

os/2 can go. that pandora config and makefile can go. several audio backends such as esd, nas, arts can go.

flibitijibibo commented 1 year ago

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.

sezero commented 1 year ago

That visualtest thing can go too: no one maintained it, ever..

slouken commented 1 year ago

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.

icculus commented 1 year ago

os/2 can go

Literally did not expect Ozkan to say this. :)

For Windows audio we can technically remove every backend that isn't WASAPI

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? And Vista...? ...And 7 and 8...? :)

Where should we cut on this?

icculus commented 1 year ago

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.

icculus commented 1 year ago

(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).

icculus commented 1 year ago

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?

flibitijibibo commented 1 year ago

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.

icculus commented 1 year ago

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).

slouken commented 1 year ago

But, legit question: we're dropping WinXP support, right? And Vista...? ...And 7 and 8...? :)

Where should we cut on this?

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. :)

slouken commented 1 year ago

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.

There will always be arbitrarily named audio devices. :)

slouken commented 1 year ago

The "raspberry" video driver can go (modern Raspberry Pi OS supports kmsdrm on at least the Pi 3 and Pi 4, if not others).

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.

I think we delete the DirectFB code, which I am not convinced ever worked in SDL2.

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.

What is "vivante"? Is this still used?

Yes, Steam Link hardware, still supported by Valve. ;)

How about riscos?

We've gotten some recent commits for this, we should reach out to the author and get their opinion.

In joysticks, if "iphoneos" is still used, let's rename that to ios.

Not only is it still used, it's the recommended path going forward for macOS. It definitely needs to be renamed though.

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).

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.

slouken commented 1 year ago

What about Haiku?

flibitijibibo commented 1 year ago

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.

icculus commented 1 year ago

Haiku is still in active development, I'm inclined to keep it for now.

icculus commented 1 year ago

We still have random folks working on embedded systems that use DirectFB - it was their only alternative once we removed fbcon support.

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.

slouken commented 1 year ago

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.

This seems like a good option, and there's already a request for it in https://github.com/libsdl-org/SDL/issues/6561

sezero commented 1 year ago

os/2 can go

Literally did not expect Ozkan to say this. :)

Well, why not. Obviously I'm not experienced enough to keep supporting and maintaining it. And since sdl3 is supposed to be more gpu-centric, there will be no point in keeping it.

sezero commented 1 year ago

Can "jack" audio go away now that pipewire is the new hotness?

Seconded

sezero commented 1 year ago

If dsp can go along with all the other legacy Unix backends,

It might be wise to still keeping it, at least for some time? Isn't that still the default for freebsd guys?

sulix commented 1 year ago

For Windows audio we can technically remove every backend that isn't WASAPI

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.

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? e.g., SDL_Surface-style software rendering only needs a framebuffer. The new GPU API will need a ~Vulkan era GPU. SDL_Renderer will need something in-between (if we're dropping GLES 1 support, do we require shader support? or do we continue supporting everything via the software renderer).

iryont commented 1 year ago

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?

Agreed, about time to focus mainly on shader capable renderers. PSP, Vita, PS2 and Nintendo 3DS can live inside SDL2 branch.

ccawley2011 commented 1 year ago

How about riscos?

We've gotten some recent commits for this, we should reach out to the author and get their opinion.

I'm still interested in maintaining this, and would be keen to see it continue to be supported in SDL3.

If dsp can go along with all the other legacy Unix backends,

It might be wise to still keeping it, at least for some time? Isn't that still the default for freebsd guys?

If we're keeping RISC OS support, then we'll need to keep this as well.

Well, why not. Obviously I'm not experienced enough to keep supporting and maintaining it. And since sdl3 is supposed to be more gpu-centric, there will be no point in keeping it.

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?

icculus commented 1 year ago

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.

slouken commented 1 year ago

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.

Kontrabant commented 1 year ago

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.

sezero commented 1 year ago

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.

flibitijibibo commented 1 year ago

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.

Kontrabant commented 1 year ago

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.

You got the enum, but the bit in the struct is still there: https://github.com/libsdl-org/SDL/blob/47c37a8e9d3128af922a4f37ae0e98c6f9067850/include/SDL_syswm.h#L289

sezero commented 1 year ago

You got the enum, but the bit in the struct is still there:

https://github.com/libsdl-org/SDL/blob/47c37a8e9d3128af922a4f37ae0e98c6f9067850/include/SDL_syswm.h#L289

Removed.

sezero commented 1 year ago

Should we remove android-project-ant directory? It isn't in make dist

sezero commented 1 year ago

Removed many things. Remaining in the list above are WinRT and opengles.

To remove WinRT, is the following precisely correct?

DanielGibson commented 1 year ago

Is winrt really irrelevant? Isn't that still used at least for the limited development possible for xbone without a proper devkit? And is it still required when targeting windows store (is that still a thing)?

flibitijibibo commented 1 year ago

Windows Store no longer requires UWP, you can use either Win32 or GDK on PC.

Xbox targeting is possible via UWP but that's saying very little in 2022 - it's vastly different from GDK, is far less stable now that it's deprecated (in the last year I think we've hit two major Xbox OS regressions, and in one instance Microsoft just pulled the games from the store instead of fixing the obvious bug!), and UWP store presence is absolutely terrible (seriously, try to find the UWP games without looking it up). So we could support it, but Microsoft definitely does not anymore.

sezero commented 1 year ago

Removed opengles with commit 30b1ab2addc48cb753c87c68d6fe6602831f88a2:

sezero commented 1 year ago

To remove WinRT, is the following precisely correct? [...] Windows Store no longer requires UWP, you can use either Win32 or GDK on PC.

Is WinRT removal a go?

CMake side: Remove all WINDOWS_STORE stuff? (@madebr ?)

I guess the emoji reaction translates to yes?

flibitijibibo commented 1 year ago

Removed many things. Remaining in the list above are WinRT and opengles.

To remove WinRT, is the following precisely correct?

* Remove `VisualC-WinRT` directory entirely

* Remove all code guarded by `__WINRT__` ?

* Remove all `! __WINRT__` guards ?

* CMake side: Remove all `WINDOWS_STORE` stuff? (@madebr ?)

* Remove all `WINAPI_FAMILY_WINRT` stuff (e.g. in SDL_platform.h) ?

We can also eliminate the winrt portion of wasapi, and move the win32-specific path into wasapi.c.

sezero commented 1 year ago

WinRT removal done in commit dc2a3e06e9218cd269f077c34d7adf709de133e0, which is intrusive.. Here is its TODO list which I'm leaving to others' love & care:

flibitijibibo commented 1 year ago

WASAPI merge is done: https://github.com/libsdl-org/SDL/commit/57458588ee905f2a0c22e7567517de2a200e2780

Kontrabant commented 1 year ago

(i.e. old wl_shell junk)

It looks like the last wl_shell remnant is one line that remained for ABI compat: https://github.com/libsdl-org/SDL/blob/57458588ee905f2a0c22e7567517de2a200e2780/include/SDL_syswm.h#L252

The rest was ripped out last year.

dos1 commented 1 year ago

Can "jack" audio go away now that pipewire is the new hotness?

I'd say it's too early for jack to go, not every distro has even switched to PipeWire yet and Pulse+JACK setups still remain popular for pro-audio purposes. jack should eventually be removed together with pulseaudio, not earlier.

icculus commented 1 year ago

Is -Wl,-framework,OpenGLES linkage needed?

I'm surprised this was ever needed, but I assume it's 100% not needed now.

slouken commented 1 year ago

Can "jack" audio go away now that pipewire is the new hotness?

I'd say it's too early for jack to go, not every distro has even switched to PipeWire yet and Pulse+JACK setups still remain popular for pro-audio purposes. jack should eventually be removed together with pulseaudio, not earlier.

@sezero, can you put jack back?

sezero commented 1 year ago

Can "jack" audio go away now that pipewire is the new hotness?

I'd say it's too early for jack to go, not every distro has even switched to PipeWire yet and Pulse+JACK setups still remain popular for pro-audio purposes. jack should eventually be removed together with pulseaudio, not earlier.

@sezero, can you put jack back?

Done.

Should we make it default to disabled, or still keep it enabled?

sezero commented 1 year ago

Is -Wl,-framework,OpenGLES linkage needed?

I'm surprised this was ever needed, but I assume it's 100% not needed now.

Removed now.

ccawley2011 commented 1 year ago

Removed opengles with commit 30b1ab2:

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.

slouken commented 1 year ago

@sezero, can you put jack back?

Done.

Should we make it default to disabled, or still keep it enabled?

Let's leave it enabled.

slouken commented 1 year ago

Removed opengles with commit 30b1ab2:

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.

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?

slouken commented 1 year ago

@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!