SFML community forums

General => Feature requests => Topic started by: Austin J on February 18, 2016, 02:54:01 am

Title: Vulkan Support
Post by: Austin J on February 18, 2016, 02:54:01 am
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.
Title: Re: Vulkan Support
Post by: GraphicsWhale on February 18, 2016, 04:22:45 am
What benefit would Vulkan bring to SFML?
Title: Re: Vulkan Support
Post by: Austin J on February 18, 2016, 05:23:52 am
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.
Title: Re: Vulkan Support
Post by: victorlevasseur on February 18, 2016, 11:38:28 am
Vulkan is also compatible with less GPUs than OpenGL 1.1.
Title: Re: Vulkan Support
Post by: SeriousITGuy on February 18, 2016, 01:25:32 pm
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.
Title: Re: Vulkan Support
Post by: GraphicsWhale on February 18, 2016, 02:18:54 pm
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?
Title: Re: Vulkan Support
Post by: korczurekk on February 18, 2016, 05:20:22 pm
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.
Title: Re: Vulkan Support
Post by: GraphicsWhale on February 18, 2016, 06:44:42 pm
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?
Title: Re: Vulkan Support
Post by: korczurekk on February 18, 2016, 07:17:28 pm
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.
Title: Re: Vulkan Support
Post by: GraphicsWhale on February 18, 2016, 07:51:32 pm
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.
Title: Re: Vulkan Support
Post by: korczurekk on February 18, 2016, 08:09:52 pm
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.
Title: Re: Vulkan Support
Post by: GraphicsWhale on February 18, 2016, 09:45:18 pm
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.
Title: Re: Vulkan Support
Post by: Cfyz on February 19, 2016, 01:21:30 pm
Vulkan actually has quite high hardware requirements. According to wikipedia (https://en.wikipedia.org/wiki/Vulkan_%28API%29#Compatible_hardware) (with reference to Vulkan Overview (https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf) 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.
Title: Re: Vulkan Support
Post by: dabbertorres on February 19, 2016, 07:35:23 pm
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 (https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp) (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.
Title: Re: Vulkan Support
Post by: Mario on February 21, 2016, 01:50:59 pm
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).
Title: Re: Vulkan Support
Post by: ief015 on February 23, 2016, 05:47:01 am
Vulkan actually has quite high hardware requirements. According to wikipedia (https://en.wikipedia.org/wiki/Vulkan_%28API%29#Compatible_hardware) (with reference to Vulkan Overview (https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf) by Kronos from june 2015), Vulkan requires OpenGL ES 3.1 or OpenGL 4.x level hardware.

it requires opengl es 3.1/opengl 4 level hardware *and* updated software. AMD recently stopped supporting the drivers for my hd5850, which does support opengl 4, but the latest supported drivers for my card does not support vulkan.

this pretty much means, as far as common descrete graphics cards go, you need at least a gtx 6xx/hd6xxx series GPU or newer to run vulkan (on official drivers).
Title: Re: Vulkan Support
Post by: zsbzsb on February 26, 2016, 05:40:52 pm
Honestly what I would like to see instead of just support for say Vulkan or OpenGL ES would be support for interchangeable backends. That way even if say SFML officially doesn't want to support DirectX the community members could more easily contribute something like that. That in itself would give SFML the flexibility to work on just about any hardware/platform if someone was willing to contribute the backend.

Interchangeable backends are pretty much what we already do when it comes to supporting multiple platforms, so why not make it the same when it comes to the rendering APIs?

AMD recently stopped supporting the drivers for my hd5850, which does support opengl 4, but the latest supported drivers for my card does not support vulkan.

This is my case right now, I am currently using a HD5670 and had wanted to try out Vulkan... Won't be an issue much longer as I will be building a new rig soon, but for now it kinda sucks for people with 6 year old hardware.
Title: Re: Vulkan Support
Post by: Laurent on February 26, 2016, 06:06:51 pm
Quote
Interchangeable backends are pretty much what we already do when it comes to supporting multiple platforms, so why not make it the same when it comes to the rendering APIs?
Because it makes everything much more complicated for very little gain. SFML was never meant to be one of those multi-API rendering engine, just a wrapper on top of a low-level rendering API that already works well on all the target platforms.

I've seriously never seen any valid point in favor of a DirectX or Vulkan back-end, except that "it would be cool". People are not even supposed to care about the underlying API -- who cares that sfml-audio uses OpenAL?.

Multiple backends for the platform, on the other hand, are mandatory for SFML to run on these platforms. So this is not really comparable.
Title: Re: Vulkan Support
Post by: binary1248 on February 26, 2016, 08:16:16 pm
Warning: Wall of text, as usual.

Because it makes everything much more complicated for very little gain. SFML was never meant to be one of those multi-API rendering engine, just a wrapper on top of a low-level rendering API that already works well on all the target platforms.
You have to define what you consider "well" here. I think we've made our lives too easy for too long by labelling any use case that doesn't perform "well" as "out of SFML's scope". If something is possible and the user demonstrates that it works in principal, they have every right to do so as long as it doesn't violate behaviour described in the interface documentation.

It is true that there are different classes of applications that can be developed with SFML, some of them fit the library perfectly, and some others less so. People who are familiar with SFML will probably already have a broad idea of what these classes could be, e.g. "Tetris-clone", "Action platformer", "Voice recorder" etc.

When someone comes along who isn't so familiar with the library and does something that doesn't fit into the usual pattern, after 1 month of effort to get a somewhat working demo together, they come to the forum and all we tell them is "This isn't a typical use case of SFML, you are better off using something else.", most often "Just use raw OpenGL, it's faster for what you are doing".

Is this really the direction we want to go in? Why do we have to explain to people that there are things that you can do optimally with SFML and others that are not optimized at all? This isn't even mentioned in the API documentation. As a library that abstracts many low-level concepts away for the user, shouldn't we strive to provide an optimal solution for everything that the user is allowed to do? Either that, or we tell them early enough that some things are implemented in a suboptimal way and they should avoid using them in their use case. I prefer doing the former, it is more intuitive and makes the library more attractive to a wider audience.

I've seriously never seen any valid point in favor of a DirectX or Vulkan back-end, except that "it would be cool". People are not even supposed to care about the underlying API -- who cares that sfml-audio uses OpenAL?.
DirectX.... well.... if you ask me, there is no valid point in favour of it, especially now that Vulkan is here. ;D

Vulkan on the other hand, is designed to provide a superset of the functionality that OpenGL provides. Simply put, there is nothing that OpenGL can do that Vulkan can't, whereas there are many things that Vulkan can do that OpenGL can't. Vulkan was also designed to be implementable on a wider range of platforms than DirectX or OpenGL ever was (this is why OpenGL ES was necessary). As such, going forward, if Vulkan sees its expected adoption, it could be the only API that would need to be supported to target any and all future platforms (possibly including consoles).

I've followed this thread since it started, and some of the most important points still haven't been mentioned.

1. Vulkan is consistent, even across vendors and/or platforms.

This means that in theory, all conforming implementations should deterministically produce the same framebuffer contents given a specific input. This means, if SFML were to support Vulkan e.g. on Windows and Linux, there would be absolutely no perceivable graphical difference when you are running in fullscreen. As everybody should know by now, this is hardly ever the case when writing for both platforms using the OpenGL backend. With Vulkan, testing on both platforms is still necessary, but the number of adjustments that have to be made would be kept to a minimum.

Just to give you a feeling for how strict Khronos is with their conformance tests, this is a list of products that have passed:
https://www.khronos.org/conformance/adopters/conformant-products
One might notice, there are no AMD products there... yet. This is both a good and a bad sign. Good because it is proof that we are guaranteed that we no longer get bogus implementations from the IHVs before they even make sure that they function correctly. Bad, because it's a sign that AMD is having difficulties as usual, considering as well that they have much less hardware (and therefore test effort) that supports Vulkan in the first place. ::)

2. Vulkan is predictable.

Remember those times when you loaded those sf::Textures during a well-placed loading screen or even went so far as to offload texture loading to a separate thread? Remember the stuttering that occurred when you actually started to use those textures in your rendering? That is a result of the freedom that OpenGL implementations get. In fact they are so free, they are allowed to delay operations as long as they want, as long as it doesn't result in any externally visible effects (performance is obviously not covered by this). This means that quite literally, "magic" happens inside the driver. They try to be intelligent as much as they can, but whenever they guess wrong, you start to feel it. Even if you really know what you are doing and want to shout "Upload the textures NOW please.", OpenGL just doesn't care simply because it doesn't have to. Lately there have been more and more extensions that give developers more explicit control over the behaviour of the implementation, SFML however still uses the legacy API, which only makes matters worse. If this trend continues, one day once you have the extensions that actually provide you with 100% control, you will probably end up with something identical Vulkan.

In Vulkan, there is no more guessing. At least, no guessing that can lead to detrimental side-effects such as was the case in OpenGL. If you have looked at the API, everything is completely explicit. Any performance impacts will more than likely come from your own code instead of a sub-optimal Vulkan implementation. This is what developers want, no matter whether you write AAA games, or your 2D side-scrolling action shooter. No matter how simple your game is, players hate noticeable stuttering. This is probably why AAA developers have preferred Direct3D over OpenGL on Windows for so long, while Direct3D 11 and earlier exhibited similar problems, it was nowhere as bad as it was in OpenGL.

3. Vulkan doesn't force you to keep validation on, even when you really don't want it.

OpenGL, whether in your debug or release configuration, will ALWAYS validate whatever you do. This is a good thing, when it prevents BSODs and similar nasty effects. Kept to a minimum, it wouldn't be that bad. However, OpenGL overdoes it, by great lengths. Even if you know for certain that those 10 lines of OpenGL code can never fail, not even theoretically, there is no way to tell OpenGL to trust you and open the door for BSODs or nasty crashes. The only difference between a debug and release version of SFML in the eyes of an OpenGL debugger are all the glGetError() calls, that's it. There is no "optimized release version" of OpenGL, it quite literally is always in debug mode.

Vulkan on the other hand, makes validation opt-in. Meaning, unless you really cry for it, you are getting nothing. If you forget that one call to bind your descriptor set without validation, be prepared for some "interesting" surprises. This is also the method of development that everybody is used to: develop and test in debug, with crappy performance and checks all over the place, release with all optimizations and no checks at all. Vulkan just follows what everybody would consider common practice.

4. Vulkan provides more information about what the hardware/implementation really supports, so alternate code paths can be chosen if they are more suited.

One headache that many advanced OpenGL developers might know of is: How do I determine what the best way to do something on hardware XYZ is? In OpenGL, there is only the notion of "Either an extension is supported, or it isn't". We don't get any information through the API about e.g. whether some brand new feature is actually supported on the hardware or merely emulated in the driver so that IHVs can stick that "Supports OpenGL 4.5" label on their rebranded cards. What you end up doing when using OpenGL is empirically testing performance on every single class of hardware you plan on supporting. On one family a certain call leads to 50% of the performance than on another family, even from the same IHV. This might lead to really absurd differentiation code, based on the GL_RENDERER string.

While the same can still be done in Vulkan, based on its advertised extensions, it is harder for implementations to "pretend" to support something that they don't truly support. And because Vulkan is so low level, it doesn't make sense to package code blobs as an extension inside the driver when the application could do the same themselves, probably even more efficiently.

5. Vulkan actually gave a bit of thought with their WSI (Window System Integration).

Unlike the horrible mess that has resulted over the last 20 years in OpenGL, Vulkan had the opportunity to provide a "simple" (relatively), and more importantly, consistent API to connect to the diverse window systems on the platforms it supports. There is no WGL or GLX or EGL or EAGL or CGL or NSOpenGL nonsense to deal with, the implementation takes care of it for us and provides an API that encompasses everything you would expect to have to do, with a single unified API. All you have to take care of is getting a window and passing its platform specific handle over to Vulkan, the rest (pixel format, double buffering, multisampling) is uniform across all platforms. If you look at how SFML currently creates contexts, from a high-level, it's always the same process, just with completely different APIs for each platform.

TL;DR:

Vulkan basically takes everything OpenGL did wrong, and finally does it right. This lead to a more explicit, lower-level API, but that seems to be what veterans were crying for for a long time. Vulkan is what you get when hardware vendors and software developers sit on the same table to talk about the API they use to communicate with each other. One might think: That makes sense, wasn't it always like that? The answer is: Until now, not really... Everybody was part of Khronos but they never really sat at a table all at once, probably because of political reasons and because there was no drive for something new, until Mantle and DirectX 12 showed up.

SFML doesn't suffer from the things OpenGL did wrong too often, but it does suffer every now and then. If SFML would have a proper, real, supported Vulkan backend while maintaining its current API, there would be nothing left for people to complain about (as long as they target Vulkan-supporting hardware that is).

Multiple backends for the platform, on the other hand, are mandatory for SFML to run on these platforms. So this is not really comparable.
Of course it's not comparable, because a single Vulkan implementation would make these multiple, divergent backends redundant even across multiple platforms. As soon as Vulkan class hardware is broadly available (i.e. 2-3 years from now), there will only be benefits in supporting Vulkan as a "main rendering backend" whereas OpenGL would be relegated to "legacy rendering backend". Fixes would target everything at once and as I mentioned in my wall of text, the user experience would be consistent across all platforms as well.

In my opinion, SFML really should support only 2 APIs, OpenGL and Vulkan. OpenGL, as mentioned, for legacy hardware and Vulkan for hardware that supports it (basically everything from 2 years ago and onward). They both share in common that they target many more platforms than e.g. DirectX does, so a DirectX renderer would make almost no sense if OpenGL and Vulkan renderers were available.

I want to get to the point where I can have a good feeling being able to tell people: "You want your SFML game to run faster? Get a better GPU." Right now, you will barely see any improvement over a decent 3-year old GPU even if you upgraded to a GTX Titan X because OpenGL is single threaded and SFML renders using the legacy API, which means: CPU bottleneck, from rendering.
Title: Re: Vulkan Support
Post by: Laurent on February 27, 2016, 10:06:37 am
Quote
You have to define what you consider "well" here. [...wall of text...]
Of course SFML is sub-optimal, but it could be much better while still sticking to (more modern) OpenGL. We could have something relatively serious with OpenGL 2/3/4; there are many AAA engines or professional libraries that only rely on OpenGL. We're (very) far from the point where only another backend could bring some improvement ;)

My point was also that with multiple back-ends, you have to use a limited API that works with all of them, so you have less room to fine-tune things and get an optimal implementation.

Quote
some of the most important points still haven't been mentioned
Thanks for this great summary :)

Quote
In my opinion, SFML really should support only 2 APIs, OpenGL and Vulkan
Sounds like an interesting plan for the future. Really.
Title: Re: Vulkan Support
Post by: Nerevar on February 28, 2016, 08:20:11 pm
SFML is not game engine,it's no need of things like directx or vulkan
Title: Re: Vulkan Support
Post by: Jabberwocky on February 29, 2016, 04:38:34 am
Great post binary.

I recall in our previous debates, you held a lot of disdain for DirectX.  One argument you provided for not supporting it was that it didn't "deserve" to be supported (paraphrasing).  And that lack of OpenGL support on some platforms could only be blamed on people caving into the demands of Microsoft to write DirectX apps.  It was a very idealist argument, but one that I could understand.

Using this same reasoning, Vulkan sounds very much worthy of supporting.  Based on your description of and enthusiasm for Vulkan, it is certainly consistent with your stance that only well designed, open, cross-platform rendering APIs be considered for SFML.

Title: Re: Vulkan Support
Post by: goodpaul6 on May 10, 2016, 01:01:35 am
Personally, I think it would be far more useful were SFML's graphics backend were to support OpenGL 3.1+ than Vulkan. The cutting-edge OpenGL features like direct state access and command lists make it basically just as performant as vulkan, and give you a similar level of control without having you rewrite the entire pipeline yourself. Moreover, with direct state access, you can sort of eliminate bugs caused by global state, and better yet is that there are far more drivers which support newer versions of OpenGL than support Vulkan.
Title: AW: Vulkan Support
Post by: eXpl0it3r on May 10, 2016, 07:20:42 am
Do you mean use OpenGL 3.1+ instead of legacy stuff?
Because SFML otherwise already supports the usage of OpenGL 3.1+ for yoir application.
Title: Re: Vulkan Support
Post by: scellow on May 20, 2016, 02:21:20 am
Vulkan is also compatible with less GPUs than OpenGL 1.1.

This is a false problem

Technology is moving, every cards that will be sold in the future will be compatible with vulkan, we are devs, we should embrace new technologies early to be ready when customers will demand it
Title: Re: Vulkan Support
Post by: Gambit on May 20, 2016, 03:18:07 pm
As it was noted before, SFML is nowhere near complex enough to even begin utilizing any benefits of Vulkan. It doesnt even utilize OpenGL 1 fully because it doesnt need to. That being said, support is not a false issue at all. If graphics cards dont support Vulkan and your application does, how do you intend on getting people to use it? For SFML's purpose, OpenGL 1 is .. Adequate. It could stand to be updated but it works now so why change it? There is nothing stopping you from using Vulkan or OpenGL 4 in your application.
Title: Re: Vulkan Support
Post by: SeriousITGuy on May 24, 2016, 11:52:55 am
One thing that came to my mind recently about this, Vulkan means no MacOS, as Apple doesn't want to support it, they want to use their Metal API for next Gen graphics.
So if SFML wants to support MacOS, their is no way around OpenGL, which will still be supported and updated by Khronos.
Title: Re: Vulkan Support
Post by: korczurekk on May 24, 2016, 12:17:28 pm
One thing that came to my mind recently about this, Vulkan means no MacOS, as Apple doesn't want to support it, they want to use their Metal API for next Gen graphics.
So if SFML wants to support MacOS, their is no way around OpenGL, which will still be supported and updated by Khronos.
They're going to write wrapper on top of Metal, so it'll work. A bit slower, but… it's something! :D

EDIT: https://moltengl.com/moltenvk/
Title: Re: Vulkan Support
Post by: Kiecker on July 03, 2016, 11:48:44 am
I don't want to burst anyone's bubble but I do know that not all drivers support vulkan, mine included  :-[ :-\
Title: Re: Vulkan Support
Post by: Gambit on July 03, 2016, 01:31:38 pm
You arent bursting anyone's bubble. This was pretty much shot down the moment it was brought up and the lack of support for legacy cards and such was also noted. Vulkan is too new and, again, doesnt have enough support to warrant using it. SFML wouldnt even begin to use its benefits over OpenGL anyway considering it doesnt even use OpenGL 1 to its fullest.
Title: Re: Vulkan Support
Post by: aggsol on July 04, 2016, 10:49:52 am
Vulkan is not going to replace OpenGL anytime soon. With OpenGL there is a standard that works on so many platforms already. I don't care what SFML uses underneath it just has to work.
Title: Re: Vulkan Support
Post by: Phanoo on August 12, 2016, 09:46:24 am
Despite the new versions, it seems that technically, SFML is stuck in 2005.
Title: Re: Vulkan Support
Post by: realArthur on February 28, 2017, 05:09:39 pm
I do not udnerstand what people are arguing here about. I don't want a high level abstraction implementation of Vulkan in SFML. I would simply need only a vkSurfaceKHR which is spoken in OpenGL the context. Without it I can't do anything. Implementing this shouldn't require that much work. It's more about platform independent implementation stuff.

I see SFML mostly as library giving me the possibilities to acquire Input Events, Sound stuff and having a window on every platform.
Title: Re: Vulkan Support
Post by: K.F on February 28, 2017, 06:55:37 pm
Try SDL then. Although I agree that making sfml a viable cross platform OpenGL ES/Vulkan frontend library can increase its popularity and extensibility, you can't get everything without enough man-hours.
Title: Re: Vulkan Support
Post by: DeathRay2K on March 03, 2017, 03:33:03 pm
SFML was never meant to be one of those multi-API rendering engine, just a wrapper on top of a low-level rendering API that already works well on all the target platforms.

I've seriously never seen any valid point in favor of a DirectX or Vulkan back-end, except that "it would be cool". People are not even supposed to care about the underlying API -- who cares that sfml-audio uses OpenAL?.

Multiple backends for the platform, on the other hand, are mandatory for SFML to run on these platforms. So this is not really comparable.
What about cases where different platforms require different rendering APIs? This would surely make it easier to broaden platform support separately from maintaining the high level API of SFML. Supporting the XBox for example requires DirectX, and even for the PS4 it may be preferable to use their GNM or GNMX APIs rather than OpenGL.
Title: Re: Vulkan Support
Post by: pinko64 on March 11, 2017, 06:15:47 am
I think sf::Window should have a constructor for a good plain vulkan-ready window.
I sure can get a window handle and create vulkan surface on sfml-window... but there's something off.

I compiled Sascha Willems's vulkan triangle sample and modified it to make sf::Window it's surface.
The original version had fps like ~1700 while sf::Window had ~250.
Tying the surface with GLFWwindow had high fps too. (oh and that had glfw vulkan defines defined)

I don't know if it's the opengl-context that drops the fps or what. But i guess it wouldn't be a big job to make one window that likes vulkan.

Oh and that comparison was tested with win10, intel igpu.
Title: Re: Vulkan Support
Post by: JayhawkZombie on March 11, 2017, 07:14:15 am
There is a lot that SFML is doing behind the scenes for you with sf::RenderWindow.  I don't imagine we should expect a really high FPS unless the devs designed it to use Vulkan.
There's a lot more work involved in using the Vulkan API.  The Vulkan implementation of SFML would probably be much larger since it expects us to do more of the heavy work.  It might be faster, but it will be more complex.  I for one very much like the simplicity of SFML's wrapper.  Vulkan does less error checking than OpenGL, so it would be easier to cause a crash.  One can use validation layers, but they can have an impact on performance.  Would SFML force the use of validation layers internally or make the programmer use them manually?
Title: Re: Vulkan Support
Post by: Repne on April 26, 2017, 10:47:29 am
Vulkan is future.
Title: Re: Vulkan Support
Post by: korczurekk on April 26, 2017, 08:07:01 pm
Vulkan is future.
Vulkan is future in applications when efficiency is really crucial. In case of SFML it's not. Same goes for CAD–like programs, simple GUI apps (aka file manager etc.) and pretty much anything that works in 2D.
Title: Re: Vulkan Support
Post by: ZeroZ30o on April 27, 2017, 02:06:55 pm
Vulkan is future in applications when efficiency is really crucial. In case of SFML it's not. Same goes for CAD–like programs, simple GUI apps (aka file manager etc.) and pretty much anything that works in 2D.

If the option isn't there, and the program requires efficiency, SFML wouldn't be an option.
My game requires an insane amount of efficiency to run bigger levels, as there is no direct limit to entities, level size...
So that efficiency would be nice, assuming the fact that I could code it (I don't know if I could do multithreading well -but assuming I could, it would be amazing).
Title: Re: Vulkan Support
Post by: Turbine on April 28, 2017, 06:42:04 pm
Vulkan is future.
Vulkan is future in applications when efficiency is really crucial. In case of SFML it's not. Same goes for CAD–like programs, simple GUI apps (aka file manager etc.) and pretty much anything that works in 2D.

Like mobile devices with underwhelming hardware and limited battery life?

I can't help but think it needs to be implemented sooner or later.. Better Vulkan than Windows exclusive Direct X.
Title: Re: Vulkan Support
Post by: Mario on May 02, 2017, 04:01:45 pm
If the option isn't there, and the program requires efficiency, SFML wouldn't be an option.
My game requires an insane amount of efficiency to run bigger levels, as there is no direct limit to entities, level size...
So that efficiency would be nice, assuming the fact that I could code it (I don't know if I could do multithreading well -but assuming I could, it would be amazing).

You missed the point of Vulkan. Vulkan is fast, because it allows you to specifically do what you need. There's less overhead.

However, if you implement it in a generic way, i.e. the way SFML does, it won't be significantly faster than OpenGL (which also implements many things in a generic way). SFML can't know what you need and what's best for your program. So even if SFML would offer a Vulkan implementation, you probably wouldn't profit from it in any significant capacity. If you want Vulkan for efficiency reasons, you'll have to access it directly.
Title: Re: Vulkan Support
Post by: Turbine on May 23, 2017, 07:26:54 am
This tutorial for Vulkan shows you how to create a window, display a graphic and a tonne of other cool stuff.

https://raw.githubusercontent.com/Overv/VulkanTutorial/master/ebook/Vulkan%20Tutorial.pdf (https://raw.githubusercontent.com/Overv/VulkanTutorial/master/ebook/Vulkan%20Tutorial.pdf)
Title: Re: Vulkan Support
Post by: I_HATE_FIDGET_SPINNERS on May 26, 2017, 08:03:06 am
I've been toying with Vulkan for a few months now and it would be a TERRIBLE choice for SFML. In fact, it would likely be slower than OpenGL.

If you want the performance of Vulkan, use it directly. But I see absolutely zero point in using it for 2D since you won't see any performance gains.
Title: Re: Vulkan Support
Post by: stewbasic on July 31, 2018, 07:59:29 am
I see this discussion has some history, but just wondering whether Apple's deprecation of OpenGL on MacOS has changed the thinking at all about Vulkan support (or more generally, multiple graphics backends)?
Title: Re: Vulkan Support
Post by: eXpl0it3r on July 31, 2018, 09:12:18 am
Apple hasn't deprecated OpenGL (yet).

And the opinion (https://en.sfml-dev.org/forums/index.php?topic=19822.msg143017#msg143017) hasn't really changed.