Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[erendorn]

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

Are you comparing COD and Assassin's Creed to the average games on sourceforge on a one to one basis?
And then you have the balls to speak about "market" a few posts later?
Lol.

[log0]

Oh, well, that explains a lot Sorry, when I read that it's comparable to Java and jar files, I immediately assumed that SPIR-V has to be some bytecode that's meant to be directly converted to machine code at runtime.
But SPIR-V thus really is a programming language that's readable and writable by humans, exactly like LLVM.

So, if you say that they moved the compiler frontend out of the driver, did you mean that the driver itself now only can handle the IR of SPIR-V, and converts it to machine code which then gets executed on the CPU?
If yes, is Vulkan the API that provides functions to convert IR to machine code & execute it?
If that's also true, I have to ask again: What's OpenCL for then? Doesn't its API provide similar functionality?

It is not human readable, at least not in raw form:

A Simple Binary Intermediate Language for Graphical Shaders and OpenCL Compute Kernels

The driver will only deal with the IR, compile it into GPU machine code. Vulkan API will not deal with IR conversion, this happens in the driver. It will have a function to pass the IR blob/shader to the driver.

OpenCL is more generic, doesn't deal with graphics specific things like draw calls and co.

[VanCoding]

Thanks dragorth and erendorn!
You've exactly given me the answers I was looking for. Everything is much clearer now

[dragorth]

Thanks dragorth and erendorn!
You've exactly given me the answers I was looking for. Everything is much clearer now

Glad to have been of help.

[Geri]

@Geri

Is your own engine running too slow or do you think it is fast enough? Many engines that are used for shooters or in future for VR really need maximum speed - did you think of 4k gaming yet? If there is a driver overhead that can be optimized in a better way, why don't use it? Vulkan does not restrict you to use a specific shader languge, for Mantle you would have needed to use HLSL (which is why that API would be a bit useless on Linux imho). GLSL will be most likely supported first, but basically other languages could be supported as well.

-my new game engine uses software rendering, therefore, there is no driver overhead. i run things with default in 320x160 resolution for 3d rendering (30-40 fps), and default 1024x512 for 2d rendering (70-150 fps). 4k rendering is not possible due to the technology i used in the renderer, i sacraficed resolution for polygon count. maybe on strong new i7 cpu-s, rendering in 1024x512 would be possible in some cases.

-my old engine used opengl to render, its written on the opengl 1.0 specifications, later i added multitexturing extensions, vertex buffer object extensions support + vertex arrays, arb shadowing, and texture compression. it had very lot of issues. for example, 30-40% of the users does not even heard about graphics drivers in his/her entry life, therefore, there was issues executing it on configurations without drivers (and default windows drivers does not always have opengl, or any 3d at all). the another significant problem was the draw calls, or more precisely, the api function calls you mentioned before. i did 100.000 - 1.000.000 in every frame, which is capped the running speed below 30 fps even on the top computers. i made some optimisations, and decrased the function call number a bit, alowing the thing to run above 30 fps. the third, and most significant problem was that intel made some creepy thing in they drivers at some point, which resulted my engine to crash. i fixed it on several intel igp-s, but i was not able to fix it in general. also, the opensource drivers was only able to move the game with 2-3 fps, while the closed source drivers operating 10x faster with it. so as a concludion, above a point in complexity/graphics quality, 3d apis are not a solution for a game meant to be sold to mass. (i pretty sure this applies on d3d, and will apply on vulkan too, lets no have dubts about that). by default, i runned this in resolution 800x512 (20-30 fps). switching to larger resolution was possible, due to the limitation was more likely in the api itself, and not in the raw processing power. (so actually 4k gaming is a factor where opengl api does not limits you.)

so basically i had to change to software rendering, to adress all of these bugs and problems.

that was neither a dream, becouse i agressively use acceleration structures, there were a lot of crash with the early versions, memory leaks, slowdowns, but it was/is still *much* easyer to deal with it, compared to wasting the time on a 3d api.

the compatibility of my software rendered engine is much higher (basically 100%) than the compatibility of my old opengl engine (30-40%) even if i supported anything starting from opengl 1.0.

so perfect solutions never exist, i would say both of my engine is very slow and ugly, so there is no change in that, however, at least i was able to maximize compatibility.

there is two thing that bothers me a bit, is the resolution, and a half second blockage when the acceleration structures must be partially recalculated, that ruins the gameplay. both is due to the behaviours of my real time ray tracing algorythm i used.

so basically i sacraficed the resolution in the favour of having xx billion polygons, very large scene, and getting all kind of effects cheaply from a few code line. but it can do in different ways to, so if a programmer wants to have 4k rendering, its possible, but not by my algorythm.

Right now there are many games that run much slower with OpenGL compared to DirectX, like Serious Sam 3 - even with a native port. On Windows you can expect that major games got replaced optimized shaders by the main gfx vendors, that means Nvidia or AMD are optimizing your code for free if your game/engine is a success, maybe they help you even with your code directly. I really hate to say that there are only few games with native Linux port which run fast. Some are only fast with Nvidia gfx, not sure what AMD/fglrx does differently (most likely not multithreaded). I expect as soon as SPIR-V is used the optimzation part is much simpler/generic than replacing full high level shader code MANUALLY - AMD did that not for CS:GO binary yet btw. What do you think gives the game related speed boost in (mainly) Windows driver updates?

depends on what api do you compare. the classic opengl will be always a dinosaur, there is too many features and extensions that must be supported, very lot of special paths, special bits and flags, large code must be runned, recorded, its speed is the same or a bit faster than directx9. if we compare it with directx11, we would get the result that the classic opengl is a bit slower, and becouse the new opengl core profiles are unoptimized (almost nobody uses them), it will be, again, slower than the directx11. there is possible to incrase it speed with new drivers, but there is no real demand on those apis, so manufacturers not really focusing on optimizing them.

and about the shaders, its all the same. shaders in directx, and shaders in opengl (glsl) basically the same language. of course, the function names are different in a lot places, but its basically identical. the drivers will compile and morph the same code from them.

i think you should not expect that these AAA games will be faster on linux, even if they would ship a few with vulkan, these factors would remain the same.

[Geri]

Are you comparing COD and Assassin's Creed to the average games on sourceforge on a one to one basis?
And then you have the balls to speak about "market" a few posts later?
Lol.

i am terrible sorry for ruining your imaginary AAA gamerworld through dishonesting the holy assassin's creed by mentioning games from sourceforge on the same page

[erendorn]

i am terrible sorry for ruining your imaginary AAA gamerworld through dishonesting the holy assassin's creed by mentioning games from sourceforge on the same page

You can cite them on the same page. But not imply that they weight anywhere near the same (this is not a democracy).

I assume that video games works just like everything else in the world, ie the majority of the revenue is generated by the minority of the games, and thus it's completely useless to cite 50 000 games, when the first hundred are all that count.
There's less data for mobile games, but I'm pretty sure the main titles use recent OpenGL ES versions too.

The rest of the games don't matter neither to Khronos, nor to platform developers, nor hardware manufacturer, so their opinion and usage is pretty much moot.

[Geri]

You can cite them on the same page. But not imply that they weight anywhere near the same (this is not a democracy).

okay, well the PC AAA gaming, which weights around 1% of the total game industry in revenue, its still totally irrelevant, including vulkan. so here is the notdemocracy for you.
so its very strange, why are you jumping on how irrelevant examples i am putting up, while this whole discussion and article is from a minimal, irrelevant, dead community (pc aaa) with a share even below the statistic failure rate, and basically zero community and acceptance.

[clementl]

okay, well the PC AAA gaming, which weights around 1% of the total game industry in revenue, its still totally irrelevant, including vulkan. so here is the notdemocracy for you.
so its very strange, why are you jumping on how irrelevant examples i am putting up, while this whole discussion and article is from a minimal, irrelevant, dead community (pc aaa) with a share even below the statistic failure rate, and basically zero community and acceptance.

I doubt the ratio is already 100:1, seeing that the market watchers expect mobile games to surpass console games revenue this year.

The PC gaming market may be a niche (if you can call 125 million-user market a niche), but there are still a bunch of gamers out there that will to fork over $60 for a new game. No matter what you think of it (I certainly would never pay that much for a game), there's enough money in there to move some mountains. Or at least hills.

DirectX lives, still it almost exclusively serves this smaller market. Vulkan is probably the same: it will be used for PC games, but mobile games certainly not within the next 5 years.


P.S. And I don't care about Assassins Creed either. The most hardcore game I play nowadays is Minecraft. But I know what's going on in the more serious gaming scene, because I'm surrounded by gamers.

[BeardedGNUFreak]

I get it, your whole account is just to troll people. But can you at least show a little humor or originality? This is just lame.

Shut your dimwitted mouth.