Vulkan Support

[Austin J]

I would have opened this discussion before posting the github issue if I had read the contribution guideline first. I apologize for not doing that.

Obviously this would be a pretty long term goal, but I think it's important to think about for the future.

I haven't read much of the Vulkan specification, but despite some of its structural differences, I haven't seen any reason SFML's current public API couldn't wrap it well. Perhaps there would be a need to add some namespacing to seperate OpenGL and Vulkan details. Parts of the API like

sf::Texture::bind

that edge closer to more direct OpenGL control might need to be reconsidered if adding Vulkan, just a thought.

How SFML would theoretically support rendering in Vulkan in the public API I feel could be taken in two obvious approaches. ( And some others I haven't thought of I'm sure)

The first approach could be two different versions of SFML being developed(vGL and vVulkan), and users choosing which one they want to use. Personally I wouldn't go with this approach, but I wouldn't know better than the team.

The second approach could take after Irrlicht. In the public API, somehow the user could have to specify whether they wish to render using OpenGL or Vulkan. Some sort of render device selection.

It might be wise to let Vulkan gain a little maturity before seriously considering this, but I feel it's not to early to discuss.

[GraphicsWhale]

What benefit would Vulkan bring to SFML?

[Austin J]

What benefit would Vulkan bring to SFML?

One benefit that Vulkan has is that its API doesn't have 20 years of cruft. This is mostly irrelevant for SFML however, since SFML abstracts the details of the rendering process away.

There are some other benefits that would be good however.

1.)One benefit Vulkan brings is that it inherently reduces CPU workload for rendering. A Vulkan powered app will likely require less time for the CPU to spend handling the overhead than an OpenGL counterpart.

2.) Vulkan is better designed for multi-threaded applications. Unlike OpenGL, Vulkan has been born in a time of multi-threading computing, and is better designed for multi-threading.

The cons of Vulkan vs Opengl is essentially just that Vulkan is obviously much less mature, and that Vulkan is much more complex and verbose. The maturity is an issue. The complexity and verbosity is why would want libraries like SFML to wrap Vulkan in the first place.

[victorlevasseur]

Vulkan is also compatible with less GPUs than OpenGL 1.1.

[SeriousITGuy]

Vulkan is also compatible with less GPUs than OpenGL 1.1.

Well if you could supply some evidence for that would be cool. Since what I read about Vulkan, it's supported on every hardware OpenGL is currently running on, it just depends if you get a Vulkan driver for that stone age GPU only supporting OpenGL 1. And since the next major SFML Version will get away from OpenGL 1 (I remember some of the devs stating that somewhere here in the forum) in favour of newer OpenGL, this point is defeated in itself. And if you still sit on OpenGL 1 Hardware and need to support it, don't upgrade to a newer SFML release, you can stick with older versions of SFML if you need to without problems. So this is not a valid argument to stay away from innovation.

At the moment I don't seed the "urgent" need to support Vulkan, as everything SFML does with OpenGL, it does so very well. Also Vulkan is the new kid on the block, and as OpenGL has already stood the test of time, let Vulkan mature before really investing time and brainpower into it. Let the big ones play with it first, let them iron out the child deseases and then it's time for a library like SFML to support it.
I see only one real pro argument, and this is the whole validation layer thing, which helps develop "safe Vulkan code", otherwise you crash your graphics drivers at runtime, which helps in overall better code quality. And the new shader format sounds interesting, and it is portable which is also a big plus for cross platform games.
TLDR: Maybe when it's time, but I don't feel like this time is now.

[GraphicsWhale]

One benefit that Vulkan has is that its API doesn't have 20 years of cruft. This is mostly irrelevant for SFML however, since SFML abstracts the details of the rendering process away.

I think this would be purely a reason for the developers of SFML to choose Vulkan, not the users, since, as you've said, SFML hides away all this stuff.

Besides, SFML uses a very old version of OpenGL that lacks any of the newer efforts to streamline the API. I'm led to believe the team doesn't really care about all this "20 years of cruft".

I would think it'd be cool to see it support opening a Vulkan window, but it appears as if the next version of GLFW will do that, so if you're simply wanting to try out Vulkan it's not all that urgent.

1.)One benefit Vulkan brings is that it inherently reduces CPU workload for rendering. A Vulkan powered app will likely require less time for the CPU to spend handling the overhead than an OpenGL counterpart.

Very true. But that's really only an issue with (high end) 3D graphics, not 2D.

And also consider, like I've said, that SFML uses a very old version of OpenGL, I'd think it'd be more important to start using a newer version of that before deciding if Vulkan would actually help (and it probably wouldn't).

2.) Vulkan is better designed for multi-threaded applications. Unlike OpenGL, Vulkan has been born in a time of multi-threading computing, and is better designed for multi-threading.

So? I'm going to go out on a limb here and assume that most games using SFML aren't multi-threaded.

Vulkan is also compatible with less GPUs than OpenGL 1.1.

Well if you could supply some evidence for that would be cool. Since what I read about Vulkan, it's supported on every hardware OpenGL is currently running on, it just depends if you get a Vulkan driver for that stone age GPU only supporting OpenGL 1.

Vulkan wouldn't be able to run on a GPU that only supports OpenGL 1.x because Vulkan requires shader support, among a great many differences between it and modern hardware that could easily prove to make Vulkan impossible to run on those devices.

Besides, if there's no driver support why does it matter?

[korczurekk]

2.) Vulkan is better designed for multi-threaded applications. Unlike OpenGL, Vulkan has been born in a time of multi-threading computing, and is better designed for multi-threading.

So? I'm going to go out on a limb here and assume that most games using SFML aren't multi-threaded.

The biggest problem of multithreading in SFML is the fact, that only one thread can draw to window at once, Vulkan is ready to take instructions from many threads.

[GraphicsWhale]

Drawing from multiple threads is a neat idea, but in practice it's a next to useless feature (i.e. nobody will ever need it, let alone use it) outside of serious 3D applications who absolutely need the extra performance.

Most of the people who use the graphics module aren't looking for some awesome library that meets the performance needs of the most demanding 3D AAA games, they just want to draw a few sprites.

Adding Vulkan would be a huge task, and for what? An unnoticeably faster graphics module?

[korczurekk]

Drawing from multiple threads is a neat idea, but in practice it's a next to useless feature (i.e. nobody will ever need it, let alone use it) outside of serious 3D applications who absolutely need the extra performance.

Most of the people who use the graphics module aren't looking for some awesome library that meets the performance needs of the most demanding 3D AAA games, they just want to draw a few sprites.

Adding Vulkan would be a huge task, and for what? An unnoticeably faster graphics module?

SFML2 isn't designed for 'drawing a few sprites', it can be used to write huge and very powerful applications. And in cases like that Vulkan can be one of best SFML's features since years.

Btw Vulkan can also replace OGL ES so it will be easier for SFML devs to support mobile platforms like Android or iOS.

[GraphicsWhale]

SFML2 isn't designed for 'drawing a few sprites', it can be used to write huge and very powerful applications. And in cases like that Vulkan can be one of best SFML's features since years.

Ok, maybe that was an exaggeration. But I'm not quite certain about the "huge and very powerful applications" part. What applications are you referring to?

Btw Vulkan can also replace OGL ES so it will be easier for SFML devs to support mobile platforms like Android or iOS.

It wont replace OpenGL ES for some time.

[korczurekk]

Ok, maybe that was an exaggeration. But I'm not quite certain about the "huge and very powerful applications" part. What applications are you referring to?

None. :| However, I'm talking about SFML capabilities. Well, I am working at pretty big app (10k+ lines of code) but it's still in development and I dont want this post be recognised as advirsment, so forgive me not sharing it's name.

It wont replace OpenGL ES for some time.

Can I ask why? If I remember everything properly it already worked on GPUs for which OGL ES was designed.

[GraphicsWhale]

None. :| However, I'm talking about SFML capabilities.

Using SFML is more inefficient and less powerful  than directly using OpenGL (not to mention if you use OpenGL directly, you can access some of the newer features). And I'd think that with any significantly complex application, the developers would be capable of using OpenGL directly (or write a finely-tuned wrapper for their specific usage).

Obviously, whether or not it's worth using OpenGL directly over SFML is really up to whoever is writing the application. The performance of SFML may very well be fine for their usage (after all, 2D isn't very demanding).

Obviously SFML is still a good choice for 2D graphics, I'm not saying that it isn't, in fact, that's my point. You don't need Vulkan. But if you need the performance so badly don't use SFML.

Can I ask why? If I remember everything properly it already worked on GPUs for which OGL ES was designed.

Momentum. It's been around for a long time, libraries and applications use it. Almost all mobile devices already support it. Many tutorials for it. It's also easier for beginners.

OpenGL 1.x is still used, even though it should have died out long ago.

[Cfyz]

Vulkan actually has quite high hardware requirements. According to wikipedia (with reference to Vulkan Overview by Kronos from june 2015), Vulkan requires OpenGL ES 3.1 or OpenGL 4.x level hardware. It makes sense, as the the new API is to become a new standard for high-performance graphics. The older hardware they have to target, the more they will have to compromise, which contradicts Vulkan design goals.

[dabbertorres]

I don't know why people think Vulkan will run on OpenGL 1.1 hardware. Desktop wise, the only drivers for Vulkan right now are Nvidia 6xx+, Intel 5th Gen+ (Broadwell and up), and AMD (I didn't realize they supported this large of a range of hardware) actually goes back to R7 200+, including a fair amount of APUs.

The one benefit that stands out to me if SFML were to use Vulkan is easier use of SFML in multithreaded applications (not just multithreaded drawing, loading of graphical resources on a different thread would be easier).

However, SFML wants to support older hardware and OSX. Apple does not support Vulkan. There is a Vulkan wrapper around Apple's Metal in development, but that's it (for now at least).
In addition, using Vulkan would incur a lot more work for SFML devs. For instance, a hello triangle sample is almost 800 lines (it does include code for running on multiple OSs, but that's still a lot compared to OpenGL!).

Unless SFML's goals and ideals change (I doubt it, nor would ask for it), I don't think Vulkan-backed SFML will bring more pros than cons right now. Maybe once Vulkan has matured a bit, and the drivers actually leave beta, it may be worth looking at again.

Also, given that SFML tends to be used by newbies or those who want something that just simply works to get something working quickly, Vulkan doesn't bring much benefit there either.

Yes, Vulkan is a great thing, and very cool. I'm starting to play with it on the side. For SFML, I don't think it's a plausible option yet.

EDIT: I guess I just basically restated what has already been said. Oops.

[Mario]

Personally, I think Vulkan could be some nice addition for SFML3, but on the other hand there are the issues already mentioned above.

Also, what many often forget or ignore: Vulkan might be significantly faster than OpenGL or DirectX, but that's really just due to the way it interacts with your own code. For example, Vulkan won't have to tidy up things or (re-)allocate other stuff, because you should know what you want or need, so you keep the abstraction layer (here: Vulkan) from doing unnecessary work.

However, in a more generic wrapper, such as SFML, you'd always have assume such thing are necessary. For example, SFML includes code to properly set OpenGL's render state. However, in theory, you could remove that, assuming that things are always set up the way they should be. That's just some level of control that's never possible, when using some "generic interface" rather than something specifically written for your use case.

So what might SFML3 support? Personally I'd even go as far as to say that I'd consider it being more likely to purely run on OpenGL ES rather than OpenGL, DirectX, or Vulkan: There are wrappers for Windows and the other platforms support it (almost) out of the box.

Oh and not to forget the lack of tutorials, books, experience, etc. As much as I'm interested in Vulkan, I'm not going to buy a 60$ book arriving in a few months just to learn that thing properly.

TL;DR: Vulkan sounds neat, but the added layer to ensure the easy and general use will slow it down and/or make it actually harder to use (or maintain).