Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[Marc Driftmeyer]

Apple probably has the worst OpenGL implementation, so they don't deserve to be highlighted.

You read like a jilted lover.

OS X is accelerated with OpenGL 4 throughout the entire operating system. Neither Linux or Windows remotely matches the requirements of that. It is also the reason OS X is not currently OpenGL 4.4 throughout.

Windows OpenGL is more mature simply for games. Vendors in CAD/Engineering are still using older OpenGL specs. Same on OS X.

If Autodesk, ANSYS, Dassault Systems, etc., demanded OpenGL 4.5 as a baseline then you'd see it, but they don't.

Linux OpenGL is a ductape mess. Always in constant flux.

The purpose of OS X upgrades is to set a new baseline.

Sorry, but Apple supports the current OS X on 5 year old systems. You expect more? You don't even use the platform.

[GreatEmerald]

Yes (there are already such compilers). Note that you will always be limited to a subset of the language, as dynamic stuff doesn't really work on GPU.

Yes, obviously, the functions could be marked with a "GPU" keyword or something like that. So that's pretty interesting.

This all sounds like a dumb idea.

Within 2-3 years it's going to be abandoned and people will be back on OpenGL.

They should have just cleaned up OGL rather than succumbing to the hype.

Now replace "OpenGL" and "OGL" with "Xorg" and you have a pattern!

[name99]

It doesn't evolve anything new from existing mind set. It is trying force new one, which is basically stuff devs did more than 20 years ago.

You seem to be willfully missing the point. To use Apple terms, Vulkan is Metal --- the low-level API. On TOP of this, one can construct various high-level API's that meet different needs. Apple has
- CoreAnimation/Layers (for UI stuff)
- SpriteKit (for simple 2D games)
- SceneKit (for 3D games)

There is nothing stopping Khronos from defining their own version of SceneKit (or, hell, their own versions of SpriteKit or CoreAnimation), the question is: "does it make sense? what problem is it solving?"
Apple, Android and MS are going to provide their own frameworks at these levels anyway, because they each want to support their language of choice (ObjC/Swift, Java, and C#), and want the framework to fit into and behave like the rest of their OS.
Likewise the game engines only want to write to low-level APIs, so they can control everything.

So who exactly is the customer for some sort of platform neutral SceneKit?

[justmy2cents]

IMHO the more interesting is fact that the same functions are available in Mantle, they just replaced "gr" prefix by "vk", eg. vkCmdBindDescriptorSet, vkQueueSubmit, vkMapMemory, vkUnmapMemory. It looks like a Vulkan is Mantle + some minor changes.

with recent AMD Mantle announcement where they said "please focus on Vulkan or DX12", i can see only positive here. it means so much more testing went into that functionality and it won't be duplicated with NIH syndrome by competing API standards doing same thing differently. i think everyone agrees that Mantle probably was far from bad standard, for me it is opposite. i loved standard (at least what it represented) and hated how they marketed it

i think next card for me will be AMD just for this positive approach

[BeardedGNUFreak]

This turd is dead on arrival.

The idiotic name that sounds like some 12 year old came up with.

Cloning AMD's failed POS Mantle junk and calling it a day?

Khronos had been kicking ass over the past few years leaving Microsoft's crap API in the dust in features and performance.

And now they completely blow it with this garbage?

[BeardedGNUFreak]

You read like a jilted lover.

And idiotic reply is exactly why Apple's desktop gaming marketshare is an absolute joke.

I remember a long time ago when the first accelerated graphics buffers were becoming standard and Apple's garbage OpenGL implementation was absurdly slow compared to other platforms due massive overhead in needlessly recopying buffers before passing them off to the GPU. Myself and other game developers would ask Apple engineers on the Apple OpenGL development mailing list and we would get savagely flamed by the dire hard Apple fanboy developers for 'hating on Apple'.

It's a cultural problem at Apple that goes all the way back to the beginning and there is no sign of it getting any better.

[grndzro]

Jesus with this many early supporters the Participant list is going to snowball. DX12 is in serious trouble if that happens.

http://i.imgur.com/kIi1xNT.png

[zanny]

If Khronos wants to avoid the hell that was OpenGL versioning and extensions, they must have a blessed reference implementation of a Vulkan and OpenCL 2.1 -> SPIR-V compiler. Otherwise we are going to continue having every vendor doing their own broken blob implementation of the API that never works consistently across vendors and never supports the same features. They need their own JVM or CLR or Gallium project for this API desperately, just providing test programs is not enough anymore. The fact they are releasing a specification for the thing when they could much easier just provide the implementation since the targeted IR is already a published draft tells they are going in the wrong direction on this. Compare to almost any other compiler infrastructure - Python has multiple implementations but cpython is blessed and thus the only target other implementations must conform to. HTML is a standard without a reference implementation so the MS, Mozilla, and Apple/Google rendering engines all behave eccentrically, have their own broken extensions, and make web sites a huge PITA to work with since the WC3 does not "bless" one renderer as the reference.

OpenGL world would be a lot less of a shitstorm if Mesa was blessed a decade ago and someone came up with Gallium back then to provide the targeted IR, so that vendors only needed to support a winsys driver for it.

That is probably the largest advantage MS has, in that they provide the DirectX compiler infrastructure and must have some back door agreement between hardware vendors on what they drivers need to take in and spit out that isn't just DXDraw calls.

[Szzz]

If Khronos wants to avoid the hell that was OpenGL versioning and extensions, they must have a blessed reference implementation of a Vulkan and OpenCL 2.1 -> SPIR-V compiler. Otherwise we are going to continue having every vendor doing their own broken blob implementation of the API that never works consistently across vendors and never supports the same features. They need their own JVM or CLR or Gallium project for this API desperately, just providing test programs is not enough anymore. The fact they are releasing a specification for the thing when they could much easier just provide the implementation since the targeted IR is already a published draft tells they are going in the wrong direction on this. Compare to almost any other compiler infrastructure - Python has multiple implementations but cpython is blessed and thus the only target other implementations must conform to. HTML is a standard without a reference implementation so the MS, Mozilla, and Apple/Google rendering engines all behave eccentrically, have their own broken extensions, and make web sites a huge PITA to work with since the WC3 does not "bless" one renderer as the reference.

OpenGL world would be a lot less of a shitstorm if Mesa was blessed a decade ago and someone came up with Gallium back then to provide the targeted IR, so that vendors only needed to support a winsys driver for it.

That is probably the largest advantage MS has, in that they provide the DirectX compiler infrastructure and must have some back door agreement between hardware vendors on what they drivers need to take in and spit out that isn't just DXDraw calls.

You are writing some nonsense.
1. You couldn't compile Vulkan to SPIR-V, Vulkan is API while SPIR-V is intermediate representation for shaders/kernels.
2. Differently working implementations of GLSL/OpenCL/(other lang) -> SPIR-V compilers is not such a big problem because you can use only one and don't care about the rest. If different drivers will interpret SPIR-V differently this would be a huge problem.
3. JVM or CLR, WTF?
4. It doesn't make much sense to have a common implementation of low level API because if it is low level it means most parts will be vendor specific.
5. Official GLSL -> SPIR-V compiler will probably be open source. GLSL will be the first langugage for writing Vulkan shaders.

[oleid]

You are writing some nonsense.

Well, this part makes a lot of sense:

If Khronos wants to avoid the hell that was OpenGL versioning and extensions, they must have a blessed reference implementation of a Vulkan and OpenCL 2.1 -> SPIR-V compiler. Otherwise we are going to continue having every vendor doing their own broken blob implementation of the API that never works consistently across vendors and never supports the same features

A reference implementation or an official way to verify the Vulkan API is needed.