SDL_gpu and SDL_render interop

[paked]

Hi team!

Super pumped to see SDL3 coming along, especially the unified GPU API.

One thing I'd really love to see support for is interop between SDL_render and SDL_gpu. I really love the SDL_render API, it is so usable--but I'd really like to be able to augment it with shaders when I need to without writing an entire 2d rendering pipeline.

From a quick read of the current headers, I couldn't see a way to go from an SDL_Texture (potentially via a render target?) to something which could be consumed in SDL_gpu (which makes sense, considering whether or not SDL_render is using SDL_gpu is definitely an implementation detail).

Are there any plans for this? Would be interested in helping move in this direction if there's appetite.

[icculus]

I think the intention is to offer something here (nothing massive), but the GPU render backend is brand new code at this point.

[icculus]

Putting in 3.2.0 milestone, but let's see how this goes.

[thatcosmonaut]

To be perfectly honest I don't really see the point of doing this. It would be a huge amount of work for us to figure out how to cleanly share state between these APIs, and a moderately experienced programmer could write a sprite batcher for SDL GPU that outperforms SDL Render with an afternoon and a cup of tea. I think if people want the power of SDL GPU they should just learn to use SDL GPU and we are only doing them a disservice by muddying the waters.

[slouken]

I agree, if anyone needs interop with a specific backend, we have those available in the renderer. SDL_GPU is a whole new beast with lots of complexity that we shouldn't surface to applications, especially since it's very likely to change. We can look at this again in the future once everything has stabilized, but now is definitely not the time.

@thatcosmonaut, as an aside, can I ask you to spend an afternoon and cup of tea to look at SDL_Render performance, at least on the GPU backend? If there are some fundamental changes to the 2D API that would make this much faster, now's the time to make them.

[thatcosmonaut]

That's a good idea, I'll make time for that this week.

[slouken]

The separate question of "how do I use a shader with SDL renderer" is one that people have been asking for ages and the GPU API gives us an opportunity to think about it again. I'll give it some more thought.

[thatcosmonaut]

If I could offer some advice here: I don't think that is a good idea. First of all it's not really clear what "SDL Render with shaders" actually means - do clients want fragment effects on individual shaders? Do they want screen space effects? Allowing arbitrary shaders opens up a huge can of worms because shaders are dependent on other kinds of render state. Are we going to allow the client to provide arbitrary vertex definitions? At some point you have to draw a line and send people to the more powerful abstraction that they are clearly asking for, and it will turn out much simpler for them in the end.

When FNA clients ask for an "improved" SpriteBatch class, we always tell them the same thing: just write your own, it is trivial to improve on XNA's sprite batch design and the result will actually suit your rendering use case. I think a similar principle applies here. It's a lot harder to provide a general abstraction here than most people realize.

[slouken]

Fair enough. I took a look at some different shader examples, and the more interesting shaders needed way more functionality than would be possible in the SDL 2D renderer.

BTW, Godot's VisualShaders rock. :)

[paked]

Thanks everyone. I really appreciate the quick and frank responses here.

Looking forward to diving into the SDL_gpu API and writing a sprite batcher in (probably a bit more than) an afternoon!