[Proposal] SFML RHI desired?

[GummyBlade]

I was wondering what the attitude towards an SFML embedded rendering hardware interface would be as a part of the library? I feel that it is in line with the "simple" part of the SFML philosophy, and would allow for a powerful expression of graphics code without exposing native APIs.

I welcome discussion around this as I'd love to hear everyone's thoughts.
I have worked on these before, and I would love to volunteer my time towards this!

[eXpl0it3r]

What's a SFML rendering hardware interface?

[GummyBlade]

A rendering hardware interface is a layer that stands between user code and the native graphics APIs (Vulkan, D3D, Metal, etc.)

Here is a good example: [nvrhi](https://github.com/NVIDIA-RTX/NVRHI) and [OpenRHI](https://github.com/adriengivry/orhi).
One of the most well known examples is [WebGPU](https://github.com/gpuweb/gpuweb) which is very commonly used in Rust.

For SFML, I feel that one embedded into the library could be very useful.
It would be incredibly powerful to have inside of the library because I'd guess 90+% of applications that use SFML are graphics applications, and rather than trying to expand the graphics API itself, the RHI would allow users to write their own graphics applications however they want. It would ease the difficult of remaining cross platform as graphics APIs that are platform specific can more easily be added as a backend to the RHI.

There are reasons against having it in the library. For example, if graphics APIs are not part of the "media" that SFML is trying to abstract away, then it should be something left up to the user to support.

I think that there is a good case for having something like an RHI inside of the library, and that it is in alignment with the philosophy of SFML of being a "simply media layer", and it would allow for improved cross-platform support.

[eXpl0it3r]

The L in SFML stands for Library not Layer.

I mean, it's certainly quite trendy at the moment, but also not trivial at all.

What would you propose exactly?
Would you just throw an LLM at it and hope that it solves it, or do you have some expertise in this area?

[GummyBlade]

I have experience working with graphics APIs and RHIs, and I have been designing my own for a while now too.

You are correct, it would not be something trivial, and it is not the only way to have good graphics support in the library. I think that it would be something very powerful, but there are costs for it.

Are there ways to come up with a proof of concept to play around with?

[eXpl0it3r]

Do you mean a proof of concept from our side?

We currently don't have the resources to invest in something like this ourselves.
If you want to create a PoC and/or discuss ideas of how to approach it, we might find time for such discussions.

Note that the plan for SFML 4 is to move away from Legacy OpenGL and provide a more flexible frontend/backend separation, allowing potentially for multiple rendering backends.
Maybe in that there's a chance for something like RHI, but I still wonder whether it makes sense to invent yet another RHI.

If you have a broad idea on how this would look like for SFML specifically, feel free to post it here, I'll make sure that binary1248 sees it, as he's the most knowledgeable one when it comes to SFML's rendering magic.

[GummyBlade]

Oh interesting where can I see more about the SFML 4 graphics plan that sounds very interesting?
I'll look here on the forum for it.

I would like to hear more about the directions that might take as that sounds like it addresses some of the points that an RHI would.

edit: nvm I saw you linked it lol

[GummyBlade]

Just did a read-through of that discussion, and I realized a few things.

There are already some RHI-like utilities in SFML (SFML::RenderTarget, etc.)
The SFML rendering API is opinionated based on legacy OpenGL.
This adds difficulty into incrementally updating the renderer without introducing API-breaking changes.
it is decided that this is an SFML 4 issue rather than SFML 3 one.
There are discussions around what the new rendering backend(s) may be.
The contenders seem to be WebGL, Vulkan, modern OpenGL.

Definitely going to keep looking into this, and I'd definitely like to volunteer some dev time to support this.