Vulkan Support

[aggsol]

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.

[Phanoo]

Despite the new versions, it seems that technically, SFML is stuck in 2005.

[realArthur]

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.

[K.F]

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.

[DeathRay2K]

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.

[pinko64]

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.

[JayhawkZombie]

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?

[Repne]

Vulkan is future.

[korczurekk]

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.

[ZeroZ30o]

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).

[Turbine]

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.

[Mario]

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.

[Turbine]

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

[I_HATE_FIDGET_SPINNERS]

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.

[stewbasic]

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)?