SDL3: Make metal the default renderer on Apple platforms

[andreasgrabher]

Because the gpu renderer has multiple issues when used in threaded applications (https://github.com/libsdl-org/SDL/issues/11048, https://github.com/libsdl-org/SDL/issues/9698) I think metal should be the default renderer on all Apple platforms. The metal renderer does not suffer from these limitations. Multi-threading should work out of the box in 2024.

[slime73]

What about all the other platforms? Is this just a feature request to make using SDL_Render on another (single) thread a supported situation?

[andreasgrabher]

I don't know if renderers that support threaded rendering are available on other plaforms or how the gpu renderer behaves on other platforms. Therefore I opened this issue only for Apple platforms.

But of course there should be a thread-safe renderer default on any platform if available.

[icculus]

What is the specific issue with the GPU backend? Is it just the Present operation has to happen on the main thread? For the Metal GPU backend we can dispatch that to main.

[slouken]

What is the specific issue with the GPU backend? Is it just the Present operation has to happen on the main thread? For the Metal GPU backend we can dispatch that to main.

It's this call that needs to be made on the main thread: https://github.com/libsdl-org/SDL/blob/9c322386bf7f132c076d9662650cae1d9e09c1d0/src/render/gpu/SDL_render_gpu.c#L1278

[andreasgrabher]

These functions are called from the secondary thread:

SDL_RenderClear(sdlRenderer);
SDL_RenderTexture(sdlRenderer, fbTexture, NULL, &screenRect);
SDL_RenderTexture(sdlRenderer, uiTexture, NULL, &screenRect);
/* Sleeps until next VSYNC */
SDL_RenderPresent(sdlRenderer);

[Akaricchi]

Multi-threading should work out of the box in 2024.

Hot take: SDL_Render is absolutely not a "2024" API. If you want to live in 2024, use the GPU API directly. It has great support for multi-threading.

[stsp]

What about all the other platforms? Is this just a feature request to make using SDL_Render on another (single) thread a supported situation?

Just a thought: perhaps you can add a hint to request the thread-safe renderer. And on MacOS that should be Metal, while on the platforms where there is currently no such thing - software renderer?

Would it be possible to officially support threading for software renderer at least?

Hot take: SDL_Render is absolutely not a "2024" API. If you want to live in 2024, use the GPU API directly.

But sometimes you need only 2d rendering with hw-accellerated scaling and filtering.

[andreasgrabher]

Just a thought: perhaps you can add a hint to request the thread-safe renderer. And on MacOS that should be Metal, while on the platforms where there is currently no such thing - software renderer?

Would it be possible to officially support threading for software renderer at least?

That is a great idea! I would love to see such an option.

Since they moved the gpu renderer down the priority list of renderers, macOS picks the metal renderer by default again. Therefore this issue could be closed. But probably the idea with a thread-safe renderer hint could survive in a new issue?

[stsp]

But probably the idea with a thread-safe renderer hint could survive in a new issue?

Would be good. The rationale behind this request is that modern CPUs are quite capable for doing 2d (and only 2d!) rendering in software, if (and only if) that rendering is properly threaded. So with that capability, SDL will deliver the unprecedented compatibility level for any 2d-rendering software: it will suddenly not require the modern GPU (or any GPU at all), so will work on old systems, embedded systems and so on. Just like the 2d rendering actually should.

This is why many people (like myself) are opposing to remove threading from their 2d renderers. This will eliminate many of the currently supported systems.