Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[clementl]

yeah. thats why 80% of the games available on linux still using the opengl 1.0's glvertex3f vertex path right from 1994 to render. i would be very curious, how you, and other gogetter would please them to use a new api,

I'd like to see a source for that number. I don't think that function is even allowed since 3.3's core profile. Since most noteworthy engine's are requiring OpenGL 4.0+ I don't think this is really the case.

if they dont even want to use the vertex array feature from 1997. why they would switch aniway? becouse you tell them to do so? or amd tells them to do so? the world does not works like that.

They'll have to come to the conclusion themselves that investing in Vulkan is worthwhile. Seeing that the Frostbite engine already has a Mantle renderpath they will be able to support Vulkan with little effort. The Unreal Engine and Unity Engine already support a variation of API's. They are already working on DX12 support for UE4, so it wouldn't surprise me if they'd have a Vulkan renderer pretty soon.


EDIT: quickly looked it up: glvertex3f indeed requires pre-3.3 OGL. Any engine doing this wouldn't switch to Vulkan anytime soon, since performance is obviously not a primary requirement.

[Bitiquinho]

Just dreaming here...

I know its too soon to ask something like that, but, if Vulkan API ends up being really close to the Gallium3D one (as already stated here), would be interesting for mesa developers to change Gallium interfaces to match Vulkan ? Is there some internal discussion about it ?

[VanCoding]

Question

Guys, can anyone answer me some questions about Vulkan?

First of all, some people said that Vulkan is that low level that one can see it as x86 for GPUs. But isn't x86 an instruction set, that the CPU defines and actually does not need any software to exist?
If I understand it right, every GPU has its own instruction set and is not standardized like on CPUs. So, if Vulkan was a standardized instruction set, it would mean that only future cards could support it by implementing the instruction set. I don't think that this is the case. So if not, it's just a low level software API. What kind of low level functions are this? And how are they different from OpenCL? If I'm right, OpenCL already is a low level API for GPUs, that allows us to write programs that run on the GPU that would not be as fast on the CPU, because of the different architectures. Isn't OpenCL as low-level to replace Vulkan? Or are there any functions missing in OpenCL that a game needs to run? Probably video output functions?

Another thing I'm not sure if I have understood it correctly is the following:
Currently, since every card has a different instruction set, every card needs a different driver to implement the OpenGL API. Well, most drivers support multiple cards because of almost similar architecture.
With Vulkan, doesn't it mean that it we could create one signle OpenGL driver that runs on every platform, since the base is the same (Vulkan). So, this basically means that further developing OpenGL drivers would be useless, and instead we should just focus on developing that single driver to rule them all, right?

This way, games using OpenGL would also benefit from Vulcan.

Another thought that came to my mind: If all future game engines build on top of Vulcan instead of OpenGL, what happens when the architecture of new graphics cards changes so much, that it's almost impossible to write an efficient Vulkan driver? Since Vulkan seems to be this low level, that's likely to happen, right? Does Vulkan even cover all current GPU architectures?

If it happens, wouldn't we be glad if games had just used OpenGL instead? Because if the architecture changed that dramatically, we could simply create something similar to Vulkan and then build a new OpenGL driver for it, and everything would work like a charm again.

Thanks for some answers!

[Geri]

I'd like to see a source for that number. I don't think that function is even allowed since 3.3's core profile.

it would be interesting to see a source from that significant amout of real game using opengl 3.3 or 4.0 at all. (i would be satisfyed with 50000 and above) but you will not able to provide one, becouse this is never happened since these new apis versions are relased.

Since most noteworthy engine's are requiring OpenGL 4.0+ I don't think this is really the case.

this is not true. you can, for example (to unquestionably proof my standpoint) search for games on sourceforge, you will rarely find any game that requires anything above the classic 1.x opengl api.

They'll have to come to the conclusion themselves that investing in Vulkan is worthwhile.

sure. just as they invested in gpgpu, in mantle, and in opencl. probably in a dreamworld, near to Narnia.

Seeing that the Frostbite engine already has a Mantle renderpath

its very shocking to actually you are just able to point on one product as example even one year after they first released that api.
things using some versions of opengl alreday numbers above ~200,000-800,000 game when we count ES versions too (win + mac + linux + ios + android + etc).

while you are able to show ONE example to proof, how viable is mantle.

actually, there is more game engines supporting mantle in theory, a few studio also pounched they ass to the concrete to show, how interested they are in mantle....
and still basically nothing.

are you realizing that these mantle-like things are living in the same dreamworld with Microsoft Bob?

they will be able to support Vulkan with little effort. The Unreal Engine and Unity Engine already support a variation of API's. They are already working on DX12 support for UE4, so it wouldn't surprise me if they'd have a Vulkan renderer pretty soon.

unreal engine and unity engine is for content creators, it have nothing to do with real game developing. unreal have a few very unsignificant AAA and unknown B titles, and there is rarely any playable game released with them on linux. these engines on PC have zero weight.

Unity engine, however, have significant share on cell phones, becouse its easy to release something with it on phones, so there is a huge amout of software using it there.
but i still seriously dont think they will switch on Vulkan api there. Why would they do it? To risk the compatibility?

i am sorry to demotivate and destroy the expectations, but the Vulcan api goes to the vitrin, to the same line with Mantle, Microsoft BOB, Itanium, OpenCL...

The Vulkan api is a dream of corporations without the ability to make real cpu-s.

[UraniumDeer]

it would be interesting to see a source from that significant amout of real game using opengl 3.3 or 4.0 at all. (i would be satisfyed with 50000 and above) but you will not able to provide one, becouse this is never happened since these new apis versions are relased.



this is not true. you can, for example (to unquestionably proof my standpoint) search for games on sourceforge, you will rarely find any game that requires anything above the classic 1.x opengl api.


sure. just as they invested in gpgpu, in mantle, and in opencl. probably in a dreamworld, near to Narnia.



its very shocking to actually you are just able to point on one product as example even one year after they first released that api.
things using some versions of opengl alreday numbers above ~200,000-800,000 game when we count ES versions too (win + mac + linux + ios + android + etc).

while you are able to show ONE example to proof, how viable is mantle.

actually, there is more game engines supporting mantle in theory, a few studio also pounched they ass to the concrete to show, how interested they are in mantle....
and still basically nothing.

are you realizing that these mantle-like things are living in the same dreamworld with Microsoft Bob?



unreal engine and unity engine is for content creators, it have nothing to do with real game developing. unreal have a few very unsignificant AAA and unknown B titles, and there is rarely any playable game released with them on linux. these engines on PC have zero weight.

Unity engine, however, have significant share on cell phones, becouse its easy to release something with it on phones, so there is a huge amout of software using it there.
but i still seriously dont think they will switch on Vulkan api there. Why would they do it? To risk the compatibility?

i am sorry to demotivate and destroy the expectations, but the Vulcan api goes to the vitrin, to the same line with Mantle, Microsoft BOB, Itanium, OpenCL...

The Vulkan api is a dream of corporations without the ability to make real cpu-s.

*Grabs popcorn*

[clementl]

it would be interesting to see a source from that significant amout of real game using opengl 3.3 or 4.0 at all. (i would be satisfyed with 50000 and above) but you will not able to provide one, becouse this is never happened since these new apis versions are relased.

I don't know what "games" you're talking about, but with 50000 games you probably encapsulated the whole PC-gaming market. The real reason why not all that many games require OpenGL 3.3, is because most of those games require DirectX 11. Totally unplayable on Linux.
When talking about mobile games a lot of people will welcome a new and smaller API, as the current Mobile drivers are horrible (as testified by the Dolphin team). Anything that might make cross-compatibility better is a win.

And by the way: many mobile games require at least OpenGL ES 2.0, which doesn't support the fixed-function pipeline either.

this is not true. you can, for example (to unquestionably proof my standpoint) search for games on sourceforge, you will rarely find any game that requires anything above the classic 1.x opengl api.

Sourceforge? Are you kidding? That's not where the money's at. Most games you find there a pretty low-fi anyways, they don't need a more modern API.

sure. just as they invested in gpgpu, in mantle, and in opencl. probably in a dreamworld, near to Narnia.

And there was no reason to support those, no. GPGPU wasn't very great on last-gen consoles, and would require to much work to port to the PC. You would also lose to much compatibility in the progress, not many GPU's supported OpenCL in the past. But many modern Windows games require DirectCompute, Physx and Havok.
Mantle wasn't implemented broadly because it was single vendor, on one OS, on one hardware platform.
OpenCL is a GPGPU language which is not used much because developers use DirectCompute instead.

its very shocking to actually you are just able to point on one product as example even one year after they first released that api.
things using some versions of opengl alreday numbers above ~200,000-800,000 game when we count ES versions too (win + mac + linux + ios + android + etc).

Yep, and the more demanding games do really require OpenGL ES 2.0+. So no glvertex3f.

while you are able to show ONE example to proof, how viable is mantle.

Not at all. And that's not because Mantle isn't good: just because it's not cross-platform. Which Vulkan is.

actually, there is more game engines supporting mantle in theory, a few studio also pounched they ass to the concrete to show, how interested they are in mantle....
and still basically nothing.

Rome wasn't built in one day. DirectX 10's redesigned the whole API. Everything was different, and so it took a few years for studio's to support it. But now a lot of games require DirectX 11.

are you realizing that these mantle-like things are living in the same dreamworld with Microsoft Bob?

Do you realize there are already a few games that support Mantle (even though it's gonna fade away) and Valve announced Source 2 with Vulkan support already in there? Dota 2 will get an update which bring Vulkan support. It's not so much a dream anymore, but slowly becoming a reality.

unreal engine and unity engine is for content creators

Obviously. And they will use any technology that ships with the engine. If that's Vulkan, their games will be able to utilize it.

, it have nothing to do with real game developing.

Aside from the fact that they build the whole game, except the engine.
These are the guys that will build a product that's actually gonna be played by end-users.

unreal have a few very unsignificant AAA and unknown B titles, and there is rarely any playable game released with them on linux. these engines on PC have zero weight.

The Unreal Engine 4 released not too long ago. A whole fleet of games using it are on the horizon.

Unity engine, however, have significant share on cell phones, becouse its easy to release something with it on phones, so there is a huge amout of software using it there.
but i still seriously dont think they will switch on Vulkan api there. Why would they do it? To risk the compatibility?

Not to risk it: to improve it. Compatibility on phones is terrible in it's current state. Vulkan can barely do any worse than the current state. And something like Vulkan could bring so much improvement to the mobile platforms, seeing that it'll improve performance in situations where CPU's are not keeping up with the GPU (you're not going to tell me this is untrue). If the CPU is fast enough, it should still improve battery-life.

i am sorry to demotivate and destroy the expectations,

Don't worry, you failed terribly.

but the Vulcan api goes to the vitrin, to the same line with Mantle, Microsoft BOB, Itanium, OpenCL...

Comparing to very new techniques that seem to be actually adapted, to ancient products that failed to ever get any traction.

The Vulkan api is a dream of corporations without the ability to make real cpu-s.

Which apparently includes AMD, Intel, Nvidia, Qualcomm, Samsung, Imagination and Apple. So more than 99% of the CPU's on the planet.


This is a chance for the bigger boy to spread out. there are quite a bunch of games out there utilizing newer GPU functionality. It's would even making porting between consoles and PC's (or even mobile phones) easier because it's similar to console API's.

[chithanh]

Not at all. And that's not because Mantle isn't good: just because it's not cross-platform. Which Vulkan is.

Indeed, Vulkan is basically Mantle with the platform and architecture specific bits stripped out.

As one pcper commenter pointed out, Mantle and Vulkan are almost identical down to the function names and orders of arguments.

There's also some Vulkan source code:

vkCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS,
textureDescriptorSet[0], 0);
vkQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence);
vkMapMemory(staticUniformBufferMemory, 0, (void **)&data);
// ...
vkUnmapMemory(staticUniformBufferMemory);

Now let's check some Mantle64.dll code:

grCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS,
textureDescriptorSet[0], 0);
grQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence);
grMapMemory(staticUniformBufferMemory, 0, (void **)&data);
// ...
grUnmapMemory(staticUniformBufferMemory);

Vulkan is 100% similar to Mantle

Anandtech wrote similar things:

What has changed from Mantle is that Khronos has gone through a period of refinement, keeping what worked in Vulkan and throwing out portions of Mantle that didn?t work well ? particularly HLSL and anything that would prevent the API from being cross-vendor ? replacing it with the other necessary/better functionality.

And finally, a Reddit poster hit the nail on the head:

Everyone wins with Vulcan except Microsoft.

So the only ones who would be motivated to downplay Vulkan and predict doom and gloom for it are Microsoft and their business partners.

[clementl]

Guys, can anyone answer me some questions about Vulkan?

First of all, some people said that Vulkan is that low level that one can see it as x86 for GPUs. But isn't x86 an instruction set, that the CPU defines and actually does not need any software to exist?
If I understand it right, every GPU has its own instruction set and is not standardized like on CPUs. So, if Vulkan was a standardized instruction set, it would mean that only future cards could support it by implementing the instruction set. I don't think that this is the case. So if not, it's just a low level software API. What kind of low level functions are this? And how are they different from OpenCL? If I'm right, OpenCL already is a low level API for GPUs, that allows us to write programs that run on the GPU that would not be as fast on the CPU, because of the different architectures. Isn't OpenCL as low-level to replace Vulkan? Or are there any functions missing in OpenCL that a game needs to run? Probably video output functions?

No, Vulkan is a programming language like Java. Just like Java gets translated to a jar file, Vulcan and OpenCL 2.0 get translated to SPIR-V. SPIR-V is comparable to a jar file with java: it only gets translated to x86 at run-time. This ensures cross-platform compatibility.

Another thing I'm not sure if I have understood it correctly is the following:
Currently, since every card has a different instruction set, every card needs a different driver to implement the OpenGL API. Well, most drivers support multiple cards because of almost similar architecture.
With Vulkan, doesn't it mean that it we could create one signle OpenGL driver that runs on every platform, since the base is the same (Vulkan). So, this basically means that further developing OpenGL drivers would be useless, and instead we should just focus on developing that single driver to rule them all, right?

This way, games using OpenGL would also benefit from Vulcan.

This is something mesa already does. Mesa is just the OpenGL part of the driver. It needs an actual low level driver to run on.

Another thought that came to my mind: If all future game engines build on top of Vulcan instead of OpenGL, what happens when the architecture of new graphics cards changes so much, that it's almost impossible to write an efficient Vulkan driver? Since Vulkan seems to be this low level, that's likely to happen, right? Does Vulkan even cover all current GPU architectures?

If it happens, wouldn't we be glad if games had just used OpenGL instead? Because if the architecture changed that dramatically, we could simply create something similar to Vulkan and then build a new OpenGL driver for it, and everything would work like a charm again.

Thanks for some answers!

Rudimentary techniques never change. While newer x86 binaries get better optimized, old ones still run even if they're 20 years old. And again, SPIR-V is just an intermediary format. Any vendor could have the driver alter the algorithm before compiling it.

[Geri]

I don't know what "games" you're talking about, but with 50000 games you probably encapsulated the whole PC-gaming market. The real reason why not all that many games require OpenGL 3.3, is because most of those games require DirectX 11.

previously, you calimed significant opengl 3/4 demand. so now you are telling that there is basically almost no opengl 3.3 game. which is true, thats what i told before.

also your imagination about the number of directx11 games is flawed.

http://en.wikipedia.org/wiki/List_of_games_with_DirectX_11_support

there is actually a very small number of PC games supporting directx11.
most directx-fan PC programmers actually use directx9 in they game, becouse they want to sell it, dx11 is still not yet widely supported enough (and probably never will).

Totally unplayable on Linux. When talking about mobile games a lot of people will welcome a new and smaller API, as the current Mobile drivers are horrible (as testified by the Dolphin team). Anything that might make cross-compatibility better is a win.

converting opengles to desktop opengl its not so terrible, probably a few day of work.

And by the way: many mobile games require at least OpenGL ES 2.0, which doesn't support the fixed-function pipeline either.

correct. many need opengl es2 - and many are still using opengl es1.x, becouse its just fine for them, and they dont see any point of converting it to opengl ES2 - and they will never convert it to Vulkan/whatever. They actually didnt even ported it to directx, thats why microsoft falled miserably the Metro apps market.

Sourceforge? Are you kidding? That's not where the money's at.

i would like to see, where is the money in an API'that does not even supported on 90%-99,99% of the computers (OpenGL 3.x, 4, Vulkan, OpenCL)...
you users actually want to run your software. So Narnia API-s canot be used for such purposes.

Most games you find there a pretty low-fi anyways, they don't need a more modern API.

see, you start getting the point.
(most) games dont need more modern API-s any more (or they dont even need an API at all). So, whats the point of the whole Vulkan thing?

OpenCL is a GPGPU language which is not used much because developers use DirectCompute instead.

not really... developers does not really using anything. They does not even using threads, becouse it was not required when they learn the hello world 20 years before. Only in the last 2-3 year, in very demanding applications, they started to use threads. So now, in 2015, we can say that the most machine demanding softwares are actually using multiple threads. In 2012, this was still not true. It take 10 years for programmers to start using thads actively - and thats just basically ONE LINE IN THE CODE a (createthread/pthread_create). imagine, what color they vomit, if they see any gpgpu-narnia api requiring ,,compute shaders''. also, it does not even works in the reality for the most cases. we can be thankful for having multiple cores, and for having multiple threads. thats something that works now, and will probably the only thing, that we will have in reality in the next 30 years. so yeah, the computing/directwhatever/opencl/opengl3/4 universe does not really exist outside the laboratory.

and now, we get another bullshit api, called Vulkan, that looks like some drug addict randomly mixed opengl functions with random shader dialects after consuming some heorin, and is just as unusable like the previous ones. programmers are tired of this non-neumann architectures, so i hope, it cost brutal amout of money for the manufacturers to release this api, becouse every forint on this is just a waste of money, a self-deception in a dreamworld.

Yep, and the more demanding games do really require OpenGL ES 2.0+. So no glvertex3f.

(i dont want to ruin your chain of (ill)logic, but ogles1.1 neither has that function, just to be precise, only types of the vertex arrays/elements. )

Which Vulkan is.

we alreday having opengl and opengles as crossplatform graphics api.

Rome wasn't built in one day. DirectX 10's redesigned the whole API. Everything was different, and so it took a few years for studio's to support it. But now a lot of games require DirectX 11.

that lot game is actually an insignificant tiny, countable number.

dont misunderstand me, i am not against innovations, but the Vulkan API is just not one.

Do you realize there are already a few games that support Mantle (even though it's gonna fade away) and Valve announced Source 2 with Vulkan support already in there? Dota 2 will get an update which bring Vulkan support. It's not so much a dream anymore, but slowly becoming a reality.

please, notify me if the Vulkan (or Mantle) API is reaching the 50.000th game as the main API, and the api will run on 99,5% on the computers, 99,9% from starting computers sold from 2000.

Obviously. And they will use any technology that ships with the engine. If that's Vulkan, their games will be able to utilize it. (.......) that's actually gonna be played by end-users.

users rarely actually playing with the api settings, and will rarely even actually switch the rendering to the Vulkan. If the Vulkan would be the default API, they would probably use that, but why the Vulkan, if there is OpenGL alreday?

also, it would be nice to see real games made with these engines, however, i didnt seen any.
there is basically no real games exist on these engines, just some BloodSteve14's WASD mapflyers and pleasegivemework level designers showcases.

this is far from gaming like the Moon-Earth distance. no player (does not matter that casual, or serious gamer) will EVER use anything made with these kind of engines in reality.
but this is an offtopic.

The Unreal Engine 4 released not too long ago. A whole fleet of games using it are on the horizon.

its nice to see 2017 predictions for some of the games on the list, or basically just ,,no information'' for most of it imagine, how many of these will default to the Vulkan API. Probably 0.

Not to risk it: to improve it. Compatibility on phones is terrible in it's current state. Vulkan can barely do any worse than the current state. And something like Vulkan could bring so much improvement to the mobile platforms, seeing that it'll improve performance in situations where CPU's are not keeping up with the GPU (you're not going to tell me this is untrue). If the CPU is fast enough, it should still improve battery-life.

compatibility is terribly, and vulkan will have the same compatibility problems. as i alreday mentioned, its like a male opengl creature raped a famel amd gpu running and opencl in narnia, and the little child is become a Vulkan, emitting lava silently, far away from any civilization.

Don't worry, you failed terribly.

well, if you feel that you should immediately go, and develop a vulkan game/engine/whatever, i will not stop you.

only the vulkan itself will stop you: its so broken that they wasnt even had the balls to release the sdk and the specifications publicly yet
it is so broken that they want the journalists first to write they confusing brainwashing on gamer sites, they are afraid if the real-world developers actually try it so early, they will early reveal, how bad is it in every mentionable ways.

actually, imgtec and its allies DELETING all technical comments (!) caliming that vulkan is does not makes any step forward, or not satisfyed with the new api.

this will be one of the biggest disaster in the history of API's, and will succumb everybody who invests in this technology.

Comparing to very new techniques that seem to be actually adapted, to ancient products that failed to ever get any traction.

its built on the same principles.

Which apparently includes AMD, Intel, Nvidia, Qualcomm, Samsung, Imagination and Apple. So more than 99% of the CPU's on the planet.

oh, and since when these are programming/game development companies?

and who asked them to do this api? becouse the developers isnt. who asked them, to do an api based on these principles? becouse the developers isnt. who asked them, to try releasing a new api together? becouse the developers isnt. and, finally who cares, what they want? becouse the developers isnt.

(also, imagination is just a little laughable insect in this list without the ability of further development.)

This is a chance for the bigger boy to spread out. there are quite a bunch of games out there utilizing newer GPU functionality. It's would even making porting between consoles and PC's (or even mobile phones) easier because it's similar to console API's.

i, as a developer, personally removed every piece of gpu/thirdparty api dependent code from my works since 2013.
on android, however, i still need sdl to paint on the screen, becouse i was lazy to learn how to do it properly.
but, in reality, there is no need for such craps. cpu have enough power now to do anything that we previously did with igp-s/gpu-s.

the era of graphics acceleration ended.

[clementl]

the era of graphics acceleration ended.

And whoop, you lost me. Have fun playing Angry Birds.