Is Vulkan really the successor of OpenGL?

Community Forums/Technical Discourse/Is Vulkan really the successor of OpenGL?

angros47(Posted 2016) [#1]
I've read a lot of different points of view: some people thinks it is just going to be a low level API, and that OpenGL would be implemented on it.

Would a rewriting of MiniB3D, OpenB3D and other engines be required at some point, in your opinion?

EdzUp MkII(Posted 2016) [#2]
Vulkan is the newer api for the newer cards out there to use older hardware it is still required for OpenGL. IIRC it's OpenGL 3.x+ that is required.

angros47(Posted 2016) [#3]
I see. But, in the past, OpenGL 1 was the "common denominator": a code written for it would have worked everywhere. The introduction of GLES broke that, especially with GLES2 (that removed matrix commands, and forced to write a shader always); making a program compatible with something that supports only GLES2 is not easy. I wonder if Vulkan is going to become the newer "common denominator", or if WebGL /GLES2 will get this role.

JoshK(Posted 2016) [#4]
I like the idea, but right now it has less compatibility than OpenGL and even id Software can't write a working renderer with it. The benefit is maybe a 30% performance increase on AMD cards and a modest increase on Nvidia cards. I think they are going to struggle to get people to use it.

LT(Posted 2017) [#5]
Surprised there isn't some kind of OpenGL > Vulkan translator.

JoshK(Posted 2017) [#6]
Intel doesn't support it either:

So you have Nvidia and AMD drivers, on Windows and Linux only. The only application I have tried is Doom, and it freezes up with the Vulkan renderer on Nvidia cards. So in reality, Vulkan is still just AMD's API that doesn't work on Mac.

So the problems are:
-API too complicated for developers to use (reportedly, I haven't looked into it much).
-Intel and Apple are not on board. My guess is Intel is protecting the Wintel monopoly, and Apple is just stupid.

The promise of Vulkan is a modern all-platform API, but it is not delivering that. So right now Vulkan is less compatible than OpenGL.

And please understand that I WANT Vulkan to take off, very badly. A lower-level API that is more difficult to use is very appealing, from my perspective. I want to use Vulkan, but right now it isn't delivering on what it's supposed to do.

zzz(Posted 2017) [#7]
OpenGL and DirectX shouldnt be going anywhere. Both APIs have slowly become more and more of a limiting factor for high end game development, so developers asked for more control. This resulted in mantle and subsequently vulkan/dx12 features.

Its a bit like comparing assembly vs high level languages for coding. You shouldnt use the former unless you can state specific technical reasons for it. Which is the same reason its not going to replace anything.

Rick Nasher(Posted 2017) [#8]
So what are the opinions on this effort then? Does this not hold any ground(looks great in any case):
Caffeinated3D - Blitz with OpenGL & Vulkan!

gpete(Posted 2017) [#9]
i signed up to follow Caff...but actually am excited about Josh's Bmax+B3d proposal..

Rick Nasher(Posted 2017) [#10]
Same here. 2 great initiatives.
Hope someone can pull it off finally. Keeping fingers x-ed.

Steve Elliott(Posted 2017) [#11]
It does look like Apple were all on-board with the others, bringing a cross-platform, lower level system to market. But Apple being Apple decided they would steal some toys (ideas) and go and produce their own version - and so take credit for it. I think they're calling it Metal, or Mental ;)

So Josh is right at the moment. IMO DirectX 11 and OpenGL 4 plus seem like the best options - at the moment.

As far as I can see, DirectX 12 and Vulkan haven't completely worked-out the fine details yet.

Rick Nasher(Posted 2017) [#12]
Well bring it on then JoshK(we're all waiting..)

Steve Elliott(Posted 2017) [#13]
Computer said no...I mean Mark did - sort of haha ;)

Josh didn't say which Christmas the surprise was for.

zzz(Posted 2017) [#14]
@Rick Nasher
Use as in write a engine/renderer with it :) My point was that no one needs to rewrite their inhouse renderer for their next match-3 game. Using someone elses engine on the other hand means you get the possible benefits without having to worry about getting it to work.

If it actually works out there should be no shortage of apis/renderers built on top of it for exactly this reason. Josh seem to agree.

EdzUp MkII(Posted 2017) [#15]
The main issue I see with any system is taking it on board you also take on the bugs, as long as they get fixed were OK. It's when they don't get fixed that it causes issues especially if they are game breaking.

We've had this with max in some cases with SegFaults on Linux appearing at random. Now Mark has moved on and on to MX2 it's not gonna get fixed officially.

I would love to see a community made max derivative but I don't think there is enough of us left to make it happen.

col(Posted 2017) [#16]
To answer the question 'Is Vulkan the successor of OpenGL?'
Yes it is.

It does have bags of potential - unleashing that potential is where all the difficulty lies. It's *not* that difficult to use but it is easy to get wrong and it is difficult to make a full blown game engine with it, but it will happen. As time moves on then the delicate intricacies will be exposed and things will get easier.

Personally I think now that gamers know there is a means of justifying the thousands they've spent on their gaming rig and it is *possible* to squeeze out faster better looking graphics then they could be the ones with the power to demand or boycott. If the gpu makers don't keep up their drivers then people will go to the ones that do.

Bear in mind that Vulkan is just at version 1. I mean OpenGL is at V4, D3D was at 11 ( before D3D12 which is a similar low level design as Vulkan ).
There's plenty of time to get things right. But will the masses be patient enough to wait?

One thing to remember is that it's not a magic API that makes your GPU faster than it was. If you were already GPU bound - ie if your GPU is already struggling then using the newer APIs is a waste of time and of no benefit at all, they'll only make the situation worse. If however your GPU is twiddling its thumbs between frames because the cpu is flat out issuing commands via 1 thread then having multiple threads throwing work at it will keep the gpu busy and that's where you'll see improvements.