Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Vulkan Support  (Read 58353 times)

0 Members and 1 Guest are viewing this topic.

ief015

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Vulkan Support
« Reply #15 on: February 23, 2016, 05:47:01 am »
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 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).

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: Vulkan Support
« Reply #16 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.
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Vulkan Support
« Reply #17 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.
« Last Edit: February 26, 2016, 06:08:25 pm by Laurent »
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Vulkan Support
« Reply #18 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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Vulkan Support
« Reply #19 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.
Laurent Gomila - SFML developer

Nerevar

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • XGM
Re: Vulkan Support
« Reply #20 on: February 28, 2016, 08:20:11 pm »
SFML is not game engine,it's no need of things like directx or vulkan

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: Vulkan Support
« Reply #21 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.


goodpaul6

  • Newbie
  • *
  • Posts: 1
    • View Profile
    • Email
Re: Vulkan Support
« Reply #22 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.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
AW: Vulkan Support
« Reply #23 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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

scellow

  • Newbie
  • *
  • Posts: 13
    • View Profile
Re: Vulkan Support
« Reply #24 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

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: Vulkan Support
« Reply #25 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.

SeriousITGuy

  • Full Member
  • ***
  • Posts: 123
  • Still learning...
    • View Profile
Re: Vulkan Support
« Reply #26 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.

korczurekk

  • Full Member
  • ***
  • Posts: 150
    • View Profile
    • Email
Re: Vulkan Support
« Reply #27 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/

Kiecker

  • Newbie
  • *
  • Posts: 10
    • View Profile
Re: Vulkan Support
« Reply #28 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  :-[ :-\

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: Vulkan Support
« Reply #29 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.