Godot 4 Is Focusing On Vulkan + OpenGL ES 3.0, OpenGL Likely For Godot 4.1

[tildearrow]

Not all Android devices support Vulkan so OpenGL is useful if you want to support a wider array of Android versions.

Even worse, my phone does support Vulkan but what is most ironic is that most Vulkan apps run slower than with OpenGL ES (e.g. RetroArch or even Dolphin where Vulkan is supposed to be faster).

[jayrulez]

Even worse, my phone does support Vulkan but what is most ironic is that most Vulkan apps run slower than with OpenGL ES (e.g. RetroArch or even Dolphin where Vulkan is supposed to be faster).

I haven't checked those particular softwares. However, it could mean that Vulkan is implemented poorly there. If you try to use Vulkan like you use older APIs then you're likely to get the same or worse results.

[piotrj3]

The same could be asked for GLES3 versus Vulkan, as well as WebGL 2.0 versus whatever comes out of WebGPU.
If GLES2 is not worth supporting, is any OpenGL specification worth supporting while Vulkan is already in place? Not a rhetorical question, just legitimately looking for answers and opinions.

There is much less hardware support Vulkan, comparing at least to OpenGL ES 3.0

Another thing is Vulkan is simply tricky to code into, pretty much it forces developer to use some library on top of Vulkan.

Also a lot Android devices support just Vulkan 1.0 and nothing more. And there is quite big performance uplift in most drivers that went from 1.0 to 1.1.

[oiaohm]

15? The first Intel graphics chip that is fully capable of Vulkan is only 6 years old (Skylake).
Sandy Bridge is not Vulkan-ready, and Ivy/Haswell/Broadwell only have experimental incomplete support.

This is not 100 percent right. Ivybridge/Haswell/Broadwell under Linux have vulkan 1.0 this is complete support to that level totally passing the required testsuite these days that changed in 2019. Before 2019 vulkan 1.0 with the full testsuite would die Ivybridge/Haswell/Broadwell so the problem turned out not to be incomplete the problem turned out to be that it was too complete so was advertising optional features for applications and testsuite to use that were totally screwed at hardware level that the hardware advertised able todo so having instant crash.

This is one those funny thing people were blaming the crashes that the driver had to be incomplete not considering for one min that the driver was over complete so advertising feature the hardware said it could do but really could not. When this happens this leads to a problem people come along look for a missing feature to implement find no missing feature to implement and walk way. Over complete problem need to come at from another mind set lets cut this thing down to the bare min to meet the specification if that works progressively keep on enabling things until it does not. Took a little while before someone looked at the Linux Vulkan 1.0 support from that point of view for Ivybridge/Haswell/Broadwell.

If you are windows and you are not Skylake with intel you are screwed there is no Vulkan provided by Intel for Ivybridge/Haswell/Broadwell.

Sandy Bridge not Vulkan-ready is question mark statement. No one has really attempted to see what Sandy Bridge can be made do with vulkan it did support direct X 11 compute and the intel lead developer at GDC 2015 did say was possible to have Sandy Bridge accelerate at least some of Vulkan but there would be need for software rendering other parts but intel was not going to be developing that. This is very much like crocus these days exposing opengl features on older generates of Intel hardware the intel developer never did. In theory Sandy Bridge could be made Vulkan supporting this would require some third party developer todo it. Yes the reality is that Sandy Bridge is not Vulkan-ready but it could be made vulkan 1.0 ready with hell loads of work. Yes the Dx 11 compute logic stuff for Sandy bridge is different to the Ivybridge and latter logic.

[Teggs]

It is only five years since DOOM added its Vulkan renderer and I first saw it in action, and five and a half years since the standard was set. Open GL is moving from 'will become an afterthought' to 'is an afterthought.' It will be a long sunset, I guess, but the end is in sight. All power to Zink and DXVK and such projects smoothing and accelerating the transition. I look forward to Vulkan-powered desktops and the further benefits of a growing use of cross-platform graphics API.

Vulkan didn't blow up as fast as I would like, but this is a good point to be at. It is a success, which did not seem certain when it released. And Godot is a success, which also did not seem certain, so congratulations to them as well.

[Alexmitter]

The effort to enable Vulkan in Godot started more than 2 years ago: https://godotengine.org/article/vulk...gress-report-1

Even before then, the main Godot developer rejected the possibility of making use of an existing open source graphics abstraction layer in Godot which would have immediately opened up Godot to use dx and OpenGL: https://github.com/godotengine/godot/issues/19602

It would also mean that Godot would immediately gain Vulkan support and Metal support if they were added to bgfx in the future.
That future came and today bgfx supports:

• Direct3D 9
• Direct3D 11
• Direct3D 12
• GNM (only for licensed PS4 developers, search DevNet forums for source)
• Metal
• OpenGL 2.1
• OpenGL 3.1+
• OpenGL ES 2
• OpenGL ES 3.1
• Vulkan
• WebGL 1.0
• WebGL 2.0
• WebGPU/Dawn (experimental)

What would be required of Godot to make use of bgfx? Just to work closely with the bgfx developer (who is very responsive and helpful in his community) to do the initial integration work and to learn how bgfx works. Godot could even had influenced the future development of bgfx to some extent.

However, instead of that future, today Godot has a beta level Vulkan implementation and a worse(than bgfx) abstraction layer. It cannot even support both Vulkan and OpenGL ES within three years of making that decision.

How many man hours would have been saved trying to (badly) implement Vulkan in Godot if they had just chosen to work with another open source project?

I don't have much faith that OpenGL ES 2 support will come to Godot in any meaningful way (I wouldn't miss it either though as I don't see many people gaming on that class of hardware). I have even less faith in the quality of their Vulkan implementation.

During the time it took Godot to get an alpha level quality of Vulkan support, other open source projects have implemented multiple rendering APIs in their engines: e.g. cocos refactored their graphics abstraction layer completely (https://github.com/cocos-creator/eng...derer/gfx-base Note: this is an example of a quality graphics abstraction layer) and implemented support for OpenGL ES2 (https://github.com/cocos-creator/eng...erer/gfx-gles2), OpenGL ES3(https://github.com/cocos-creator/eng...erer/gfx-gles3), Metal(https://github.com/cocos-creator/eng...erer/gfx-metal) and the aforementioned Vulkan (https://github.com/cocos-creator/eng...rer/gfx-vulkan). They could have even implemented d3d12 in that time but they just decided not to target it.

Now that's just one component of Godot that has suffered due to (IMO) a bad decision not to make use of existing open source software when they clearly don't have the resources to properly implement it themselves.

This affects other areas in Godot as well. I personally had issues with FBX import. They decided to spend time working on an half-assed fork of assimp (https://godotengine.org/article/fbx-...or-godot-3-2-4) instead of using open source software that already works like OpenFBX(https://github.com/nem0/OpenFBX). If you try to import an FBX file in Godot today, there is an 80+ percentage chance that it is somehow broken.
For reference: https://github.com/godotengine/godot/issues/46906

Both bgfx and OpenFBX are successfully used in other game engines with very good results (https://flaxengine.com/ uses OpenFBX and the majority of models I tried importing there worked and for those that had issues, the author was very quick to push fixes for).

I haven't looked much into other areas but I've at least heard about deficiencies in Godot's physics library (There are open source alternative's like Bullet and PhysX that can be used).
I know they currently have a bullet implementation but what is the sense in maintaining two different libraries for 3D physics? Just pick a properly supported one and stick with it. You're not going to do a better job at implementing a physics engine than these dedicated projects while developing all the other components of a 3D engine.
Note: Most game engines use either bullet or PhysX.

Of course it is completely okay and reasonable to want to control all aspects of your game engine. However don't pretend it is completely open when decisions that affect all the users effectively comes down to just one person and whatever he says goes. People are paying on Patreon salaries of multiple developers to work on things that could take significantly less resources if they just made use of good quality open source software as third party dependencies.

I'm happy that Godot exists. However I don't have much faith in its future development while the attitude of just one developer is a significantly impedes its advancement.

Not using BGFX was one of the best choices the Godot team has done so far.

But as the renderer head developer of Godot said, write that support, send in the code, proof him that this BGFX trash is any better.

[oiaohm]

It would also mean that Godot would immediately gain Vulkan support and Metal support if they were added to bgfx in the future.
That future came and today bgfx supports:

• Direct3D 9
• Direct3D 11
• Direct3D 12
• GNM (only for licensed PS4 developers, search DevNet forums for source)
• Metal
• OpenGL 2.1
• OpenGL 3.1+
• OpenGL ES 2
• OpenGL ES 3.1
• Vulkan
• WebGL 1.0
• WebGL 2.0
• WebGPU/Dawn (experimental)

What would be required of Godot to make use of bgfx? Just to work closely with the bgfx developer (who is very responsive and helpful in his community) to do the initial integration work and to learn how bgfx works. Godot could even had influenced the future development of bgfx to some extent.

https://github.com/bkaradzic/bgfx/issues/2537

There is a hard problem here. bgfx has had a long term quality problem here. Where due to so many backend you load up all the example programs and at some of them fail. Yes not the same ones either different ones fail with different back-ends.

https://github.com/KhronosGroup/MoltenVK

Vulkan support also gains Metal support by MoltenVK. Remember MoltenVK you have a conformance test suite there.
Using google angle with opengl ES also has a conformance test suite as well.

There is a reason why the godot developers want to work with Khronos instead of bgfx and it quality control. There is no point getting 13 backends by adding something like bgfx if the result is your developers instead of working on your project end up stuck in third party project fixing problems that should not exist in the first place if their was good conformance test suites to run in continuous integration to prevent the problems form being merged in the first place.

Its really simple to underestimate the importance of something like Khronos Conformance Tests on development and how much developer time it costs not having them.

Please note I would like to recommend something like bgfx but in the current state without good conformance/test suite its more a problem than useful.

[kaprikawn]

Not using BGFX was one of the best choices the Godot team has done so far.

^ Absolutely this.

Advocating for abstraction layer upon abstraction layer upon abstraction layer is a recipe for low performance spaghetti code that nobody has a hope in hell of debugging. One of the things that the Godot devlopers are striving towards is readable code.

[oiaohm]

^ Absolutely this.

Advocating for abstraction layer upon abstraction layer upon abstraction layer is a recipe for low performance spaghetti code that nobody has a hope in hell of debugging. One of the things that the Godot devlopers are striving towards is readable code.

Vulkan does have a option of being abstraction layer on top of metal as moltenvk. Zink in time will be a option to be opengl and opengl es on top of moltenvk. Yes of course for opengl es there is google angle as well

https://www.collabora.com/news-and-blog/blog/2021/06/14/zink-summer-2021-update/

Notice something in the zink blog."continuous integration" if you dig into moltenvk that is vulkan to metal you also find continuous integration testing. Yes google angle also has continuous integration testing on all their supported backends.

I am not anti abstraction layer over all. I am anti using abstraction layer without a decent continuous integration setup and with question able resources behind it bgfx .

bgfx is unfortunately abstraction layer of do you fell lucky. There is not a continuous integration setup covering all the back-ends that bgfx claims to support this is the best validation. bgfx does not have a software rendering only continuous integration setup either this is the second best validation option.

Lot of people forgot how bad different vendors opengl was when the Khronos testsuites where closed to end users and how much it improved when developers of application that depend on opengl could run the test suite and say hey this companies provide implementation of opengl/opengl es is broken . Its really critical if you are building on top of something that the somethinghas a test suite and it has continuous integration testing. Otherwise you end up in a game of bug wack a mole that is time wasting for everyone.

Yes abstraction layers do have a price of at times lower performance in most cases but if they are quality abstraction solutions you get a functional product/program with less developer hours. Yes quality abstraction has to have the test suite and the continuous integration testing. Non quality abstraction solution normal end up costing developers more hours than if developer had built a complete replacement to non quality abstraction themselves including test suite and continuous integration.

bgfx like or not is a non quality abstraction. I wish it was not case as these non quality abstractions look so tempting that people who don't better yet go use them and end up wasting tones of developers hours that would not have need to be wasted if time had been put into making these proper quality with test suite and conformance testing.

Yes those developing and working around the non quality abstraction layers do go around opening issues and other things on other projects because they think what they are working on is the solution then are surprised when parties like godot say no we will developer our own thank you because this is in fact the long term least hours path for them.

Yes non quality abstraction has a very hard time attracting people who will work on a quality abstraction what also endangers the projects future.

Abstraction layers can have their place. Problem is we need to sort them into two groups the quality and the non quality. The quality abstraction layers are beneficial to development the non quality abstraction layers are harmful to development. Yes a non quality abstraction layer need to be rejected from major usage until the hours are put in to get test suite and continuous integration done so moving it into the quality class of abstraction layers.