[rlvk] Vulkan support

[mandar1jn]

I'm planning on adding Vulkan support to Raylib, but there are some things I need to know first.

The goal is to be able to compile for both OpenGL and Vulkan without having to change your program.

How would you guys recommend I go about this?
Anything you'd like to see?

[mandar1jn]

So I need your opinion on something. Vulkan requires a engine version. Should that be the raylib version or the rlvk version? And there is also an application version parameter. Should that be something that just is always 1.0.0? Or should it be something that should be added to both rlgl and rlvk? And let rlgl just log it to the console? So developers can keep track of the version when in debug?

[raysan5]

Personally, I'd start with a 0.1 version until I got something functional.

[mandar1jn]

So after a period of kinda not doing anything with this, I decided to give it another shot. I'd like to have the way to go about this nailed down first. One of the first things to think about is how to get started adding Vulkan support. Someone in the discord suggested to split rlgl into a header file called rlgraphics and a .c file with all code. That way I can more easily add vulkan support and ensure that the function definitions stay the same.

[MichaelHoelzl]

Forget about Vulkan or Metal. WebGPU is maybe a better solution. Sounds like "web", but it was also designed to be used not only for the web but also natively on the operating systems for games or applications.

And here's why...
WebGPU allows platform-independent rendering in the browser and on the desktop, whether Windows, Mac or Linux. It uses the graphics interface in the background, which is available Vulkan, Metal or DirectX. An implementation of WebGPU is available from Mozilla (WGPU) and from Google (Dawn). As this is also the future of 3D rendering in web browsers, this interface will become more and more popular and will be supported by all major operating systems. And it is easier to implement than Vulkan. :-)

[wwderw]

I do think the Sokol header(s) have the ability to compile against wgpu-native. Or atleast that is on the roadmap. I bring that up just based on what is available in "external".

With SDL as a platform, would we not be able to get to Vulkan via SDL?

Warning, I know just enough to cause damage, so my ideas could be nonsensical.

[MichaelHoelzl]

No SDL would not help with Vulkan. But that's interesting about Sokol and WGPU, I didn't know that before, I'll have to try it out.
But it would make sense if Sokol implemented WebGPU. WebGPU is much simpler than Vulkan and you can use any graphics api, even Apple's Metal. I think WebGPU will replace OpenGL in the future when it comes to cross-platform graphics programming.

[truedat101]

Understood, I think it's been said by you at least 6 times on the forums that it isn't in the annual roadmap (every time the roadmap requests are posted this comes up). As experimental side projects, anyone can try out prototypes with the understanding they would need to maintain it.

[wwderw]

@MichaelHoelzl I thought SDL was about to target Vulkan, but it's very likely I'm wrong about it. I really only use SDL_Render for some things that I do with IMGUI.

Yea, Sokol headers I think are all about the web, so the focus for those implementations are first class. At least the last time that I had messed with them, but I was also using GL with it. Rust isn't my thing though, but at least they have the static libs precompiled for wgpu native.

[m1karii]

@mandar1jn
Any updates on this?

[mandar1jn]

Yes. I don’t have enough experience and don’t know how I would go about implementing it. Raylib also doesn’t really need it.

[m1karii]

It's on raysan if he decides to do it then i guess ...

[raysan5]

No plans for now.

[orcmid]

Folks who continue to want this should look at how raylib has been abstracted to allow other backends. This has already been done for SDL. Look at raylib/src/platforms. The rcore_template.c there is also instructive.

[goofyseeker311]

vulkan for hw rt. because opengl/webgl does not support hw rt.
not compute ray tracing but actual hardware ray tracing using rt cores or native rt implementation.

[MayaChen350]

I really feel like this should be more of a plan than just an idea. I'm not saying to ditch OpenGL entirely, but supporting Vulkan (maybe even by default) would most likely make Raylib more powerful than it has ever been

So I feel like there should be more of a collective effort... Maybe I'm not considering everything though but, by observation, OpenGL is starting to get replaced by Vulkan a lot nowadays... For obvious reasons: OpenGL is getting 'outdated' with Vulkan being around.

(For compatibility issues though, I guess OpenGL should stay optional. Though since Vulkan's API is pretty different from OpenGL's if I recall I don't think only a single or 2 devs can implement it on Raylib without breaking raylib.

I personally think Raylib needs an actual plannified rewrite)