Khronos Group Announces Vulkan To Compete Against DirectX 12

Phopojijo writes The Khronos Group has announced the Vulkan API for compute and graphics. Its goal is to compete against DirectX 12. It has some interesting features, such as queuing to multiple GPUs and an LLVM-based bytecode for its shading language to remove the need for a compiler from the graphics drivers. Also, the API allows graphics card vendors to support Vulkan with drivers back to Windows XP "and beyond."

Comments

let me guess, ideal hardware found indicator

[ihtoit]

a Tribble purr?

Re:let me guess, ideal hardware found indicator

[drinkypoo]

No, that sound is reserved for errors in the accompanying physics engine, Cling1.

Re:let me guess, ideal hardware found indicator

[OakDragon]

If you have problems, reverse the polarity.

Boy you know you're old

[50000BTU_barbecue]

when the only words in that headline you know are "group announces" and "compete against"...

Re:Boy you know you're old

[MrL0G1C]

DirectX 12 isn't out yet and appears to be a Windows 10 only thing. Quick check shows windows 7 has DX11. I'm assuming you know what DirectX is ;-)

Source:
http://www.anandtech.com/show/...

Re:Boy you know you're old

[50000BTU_barbecue]

I've heard the term but knowing what something "is" is quite another thing. This is probably why I can't find a job, I only claim to know things I can actually understand and explain, not the word-bingo that HR triggers on...

Re:Boy you know you're old

[Cederic]

That and your clear disdain for self-education using the bountiful resources of the internets.

Re:Boy you know you're old

[MrL0G1C]

Put simply:
Game -> Directx -> Driver & Hardware. (Perhaps DX skips the driver for some stuff, I don't know)

It's the MS Windows software framework which takes it's input from the game and outputs to the driver / hardware, it's used for controlling 2d, 3d textures etc + soun, mostly for games. The next gen stuff does more GPU computing I guess. It started with win95-ish.

Re:Boy you know you're old

[MightyYar]

Are you on the right site?

Re:Boy you know you're old

[aliquis]

From Wikipedia, Khronos group:
"The Khronos Group was founded in 2000 by companies including ATI Technologies, Discreet, Evans & Sutherland, Intel Corporation, NVIDIA, Silicon Graphics (SGI), and Sun Microsystems. It now has roughly 100 member companies, over 30 adopters, and 24 conforming members.[3] Its president is Neil Trevett.

Working Groups[edit]
OpenGL, a cross-platform computer graphics API
OpenCL, a cross-platform computation API.[4]
COLLADA, a file-format intended to facilitate interchange of 3D assets.
OpenGL SC, a safety critical profile of OpenGL ES designed to meet the needs of the safety-critical market
OpenKODE, an API for providing abstracted, portable access to operating system resources such as file systems, networks and math libraries
OpenGL ES, a derivative of OpenGL for use on mobile and embedded systems, such as cell phones, portable gaming devices, and more
OpenVG, an API for accelerating processing of 2D vector graphics.
OpenMAX, a layered set of three programming interfaces of various abstraction levels, providing access to multimedia functionality
OpenSL ES, an audio API tuned for embedded systems, standardizing access to features such as 3D positional audio and MIDI playback
EGL, an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system[5]
OpenWF, APIs for 2D graphics composition and display control
OpenML, an API for capturing, transporting, processing, displaying, and synchronizing digital media
WebGL, a JavaScript binding to OpenGL ES within a browser on any platform supporting the OpenGL or OpenGL ES graphics standards
WebCL, a JavaScript binding to OpenCL within a browser.
StreamInput, an API for consistently handling input devices.
OpenVX, Hardware acceleration API for Computer Vision applications and libraries
OpenKCam, Advanced Camera Control API"

Founded year 2000.

I assume one doesn't necessarily know all that but if nothing else for those who care somewhat I guess they should know they are behind OpenGL at least.

And kinda anyone who cares about computers to any degree of seriousness really should know what Direct X is too.

So basically it says a multi-platform 3D graphics API competitor to Microsoft 3D graphics API announces their competitior against Microsoft newest (and rather hyped possibly "revolutionary step"?) 3D graphics API.

Where DirectX 12 3D-part is supposed to be competition to Mantle which is AMDs API where they lower abstraction and CPU usage in an attempt to get more performance out of the GPU and more CPU power left for others.

DirectX handles more than just 3D graphics though, such as joystick input and sound too.

Re:Boy you know you're old

[Blaskowicz]

Nope, it's for DX11 cards and not necessarily all of them (as far as I know).
nvidia announced support for Fermi cards and up (i.e. GTX 480 etc., their first DX11 hardware), Intel for Haswell graphics and up, AMD I don't exactly know if it's for GCN only (Radeon 7970, R9 280 etc.) or if older DX11 hardware is supported (Radeon HD 5000 and 6000).

Perhaps older DX10 stuff could support much of what's needed, but nvidia recently halted driver development for their DX10 hardware (save some maintenance updates for linux) and AMD halted it long ago.

Re:Boy you know you're old

[Noah Haders]

I'm pretty sure that a sentence that begins with "the Khronos Group announces Project Vulkan to..." the only way to end this sentence is "to defeat the Avengers and impose world domination".

Re:Boy you know you're old

[khellendros1984]

Khronos Group is a consortium that creates open graphics and media standards. As an example, it's the current developer of OpenGL, which is one of the two main 3D graphics APIs. Vulkan is being designed as a next-generation replacement for OpenGL and OpenGL ES (the mobile device version of OpenGL). Part of its purpose is to unify the two APIs.

DirectX is a collection of APIs by Microsoft, which provide functions that are useful for graphics and audio applications (especially games) on Windows and in other Microsoft products.

OpenGL has been around since about 1992, and DirectX since about 1995. Your age probably isn't a factor here. More likely, you haven't had a remote interest in graphics programming in the last two decades and also haven't had close exposure to computer games, CAD, or other graphics-heavy applications within that time period.

Re:Boy you know you're old

[50000BTU_barbecue]

Hahahahahahaha1!!!!!1 LOL you think that impresses anyone when hiring????

Oh my God!!!!

Re:Boy you know you're old

[50000BTU_barbecue]

So a few weeks of reading random shit, throwing together some snippets of code that I don't actually understand, that's "employable" to you?

No wonder the economy is in the shitter.

Companies take one look at a gray hair and the resumé ends up in the shredder, initiative or not.

You'll see.

Re:Boy you know you're old

[GuB-42]

I'm assuming you know what DirectX is ;-)

Don't assume too soon, as many people don't know what DirectX really is.
DirectX is a collection of libraries for sound, input, 2D and 3D graphics, video, etc... 3D graphics and GPU computation is only part of it, and the only part that OpenGL/Vulkan compete against. There are other libraries that reproduce other parts of DirectX such as SDL, OpenAL, mplayer, ....

Uh, what?

[TheRaven64]

an LLVM-based bytecode for its shading language to remove the need for a compiler from the graphics drivers

This removes the need for a shader language parser in the graphics driver. It still needs a compiler, unless you think the GPU is going to natively execute the bytecode. If you remove the compiler from a modern GPU driver, then there's very little left...

Re:Uh, what?

[Megol]

Exactly... While removing the parsing and some types of optimizations (common subexpression elimination etc.) helps somewhat there still needs to be optimizers and code generators in the driver. One just have to remember that GPU architectures vary greatly from explicitly scheduled VLIW to partially out of order execution throughput designs to realize that the code generator alone can be pretty complex. :)

I hope Vulkan will support pre-compiled and cached shaders. That could make a huge difference for some tasks.

Re:Uh, what?

[cheesybagel]

Yeah that is basically it. It skips the source code parsing stage. It also allows software developers to ship the shaders as harder to disassemble binaries instead of source code. This is probably the main reason why they added it in the first place. NVIDIA Cg has always been like this.

There have also been problems in the past with parsers on different GPU drivers behaving in a different ways but that is less of a problem.

They still need an optimizing compiler to translate those LLVM platform independent binaries to the GPU architecture binaries. So you still need a virtual machine in the GPU driver.

Re:Uh, what?

[Arkh89]

No, the driver does not run a virtual machine. It has to recompile the bytecode in whatever-type-of-assembly the targeted GPU is taking.

Re:Uh, what?

[TheRaven64]

This post needs a '-1 not even wrong' moderation. I started to write a reply to your points, but I honestly can't tell if you're trolling or completely fail to understand any of the parts of the hardware and software stacks involved.

Re:Uh, what?

[91degrees]

Is this really something OpenGL didn't previously do? I remember DX8 drivers compiling to a bytecode. It was a pretty simplistic language, with a suboptimal bytecode but it still avoided at least one slow part of the process. I realise that optimisation takes the bulk of the time on non-trivial architectures but it still seems like a poinless inefficiency to expect a driver to even handle string parsing.

Re:Uh, what?

[gnupun]

This removes the need for a shader language parser in the graphics driver. It still needs a compiler, unless you think the GPU is going to natively execute the bytecode. If you remove the compiler from a modern GPU driver, then there's very little left...

In compiler lingo, the source code to parse tree/bytecode converter is called the front end. The piece of code that takes the parse tree/bytecode and generates native machine code is called the back end.

So the new spec removes the compiler front end from the graphics driver, greatly improving performance. Only the compiler back end is present in the graphics driver.

Re:Uh, what?

[Wootery]

You don't compile bytecode, you compile to byte code

I can't tell if you're just being obtuse, but: the developer compiles shader language to bytecode, and the graphics driver compiles bytecode to GPU native-code. Both of these stages qualify as compilation. (They're both level-reducing language-transformations.)

The entire point is that byte code is interpreted at runtime.

No. There's no way in hell that anyone's seriously suggesting running graphics code in an interpreter. Again, it will be compiled by the graphics driver. (We could call this 'JIT compilation', but this term doesn't seem to have caught on in the context of graphics.)

building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation.

Re:Uh, what?

[Wootery]

s/assembly/binary/

Re:Uh, what?

[Wootery]

Is this really something OpenGL didn't previously do?

Yup that's right, it's previously gone with the distribute-your-shader-in-source-form approach. That 'graphics driver' includes most of a C compiler.

Incidentally, OpenCL is making a similar transition, also to an LLVM-based IR.

Re:Uh, what?

[Carewolf]

You don't compile bytecode, you compile to byte code

I can't tell if you're just being obtuse, but: the developer compiles shader language to bytecode, and the graphics driver compiles bytecode to GPU native-code. Both of these stages qualify as compilation. (They're both level-reducing language-transformations.)

The entire point is that byte code is interpreted at runtime.

No. There's no way in hell that anyone's seriously suggesting running graphics code in an interpreter. Again, it will be compiled by the graphics driver. (We could call this 'JIT compilation', but this term doesn't seem to have caught on in the context of graphics.)

building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation.

Especially since the bytecode is supposed to be hardware neutral, it is the compilation from bytecode that will have to do the aggresive optimizations to adapt to the target architecture.
You can have very simple bytecode that doesn't need much processing, and while technically compilation is really compiled, but that wouldn't make sense here.

Re:Uh, what?

[Kjella]

So the new spec removes the compiler front end from the graphics driver, greatly improving performance. Only the compiler back end is present in the graphics driver.

Not if you're talking game performance rather than compiler performance I think. From what I understand games generally compile their shaders to native instructions long before they're used, it's not just-in-time compilation like when you download javascript on a page and do it on the fly as you execute, more like delayed traditional compilation until you can optimize for this particular hardware like Gentoo ebuilds.

However, the IR instructions is probably much simpler than the source language, for example Java has tons of classes but only ~200 opcodes. It would make graphics drivers not quite, but a lot more like CPUs running "assembler-ish" code instead of being huge graphics libraries. Basically you're moving most of what's OpenGL/DirectX today over into the application. Stallman might not approve but it might mean more AAA games being able to run on a thin OpenGL Vulkan shim than Mesa.

Re:Uh, what?

[shaitand]

"I can't tell if you're just being obtuse, but: the developer compiles shader language to bytecode, and the graphics driver compiles bytecode to GPU native-code. Both of these stages qualify as compilation. (They're both level-reducing language-transformations.)"

Let me put this another way. Byte code is machine code for an imaginary machine, GPU native code is machine code for an actual machine. There is no level reduction occurring when interpreting byte code, both are already machine code, there is a translation from one instruction set to another compatible instruction set. Interpreters are a form of compiler designed to run at runtime rather than well in advance, modern interpreters are JIT compilers. The JVM for instance is an interpreter.

If you start confusing the typical convention of referring to compiled vs interpreted with the fact that technically in all cases the things you are referring to are all compilers it gets confusing. There is greater specificity in saying that bytecode in this case is run through an interpreter and even more specificity in saying that the design of that interpreter is one of JIT compilation (although the term mostly exists as a form of geek marketing to avoid negative stigma of using the word interpret).

"building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation."

I'm not avoiding calling the translation compilation, as I clarified above, this is runtime compilation aka interpretation. I'm proposing that it would be faster to make the imaginary machines instruction set the instruction set physically implemented on the chip. As an intermediate but still ridiculously fast step they could add a handful of gates and perform the translation on the chip. The compiler would then be part of the SDK rather than part of the driver and you'd have compile once run everywhere shader code with the ability to hand optimize available to every developer.

It represents an excellent bit of bait to eventually get all GPU's to implement a standards based shader instruction set, much like Intel and AMD both target the same cpu instruction set.

Re:Uh, what?

[Blaskowicz]

Let me put this another way. Byte code is machine code for an imaginary machine, GPU native code is machine code for an actual machine.

Kind of like x86 code is code for an imaginary machine.

I'm just joking, trying to introduce more confusion. Though GPUs don't have "x86" or "armv7" : they all differ from each other

Re:Uh, what?

[HornWumpus]

You wrote that wall of text and don't know what an interpreter is?

Hint: What does it do the second time it runs a block of code?

Re:Uh, what?

[shaitand]

"Especially since the bytecode is supposed to be hardware neutral, it is the compilation from bytecode that will have to do the aggresive optimizations to adapt to the target architecture."

This is a confusion in terms. Personally I blame Sun. An interpreter IS a form of compiler, it is the term used to refer compilation at run time. Which is exactly what happens here. That bytecode won't be interpreted or compiled before you open the game, therefore it is runtime compilation, therefore it is interpreting. JIT Compilation == Interpreted. The only difference between a compiler and an interpreter is when they perform compilation. What is happening here is the step happening in the sdk (compilation to bytecode) and the step happening in the graphics driver (bytecode, compiled at runtime aka interpreted, and then executed). Although both are technically compilation, classically you'd call one compilation due to all the work being done in advance and the other interpretation due to the work happening just before execution.

"building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation."

I suppose if you are counting translating the machine code of the interpreter into logic gates and then physically building those gates on a wafer "compiling" that would be compilation.

As for hardware neutral, the api is a standard hardware neutral interface for developers. What difference does it make if the step which interprets the bytecode is executed as bare hardware or slower software? All software can be converted 1:1 to hardware. There are no optimizations which can be done here which wouldn't be comparable or even more efficient directly implemented in hardware. Initially it'd be a kludgy add on stealing chip die space (although not much in todays terms) but later the cards would be specifically designed to optimize the execution of that simple bytecode through the entire pipeline.

Re:Uh, what?

[Wootery]

I accept this is merely a disagreement in the meanings of terms, but really: interpretation is absolutely not another term for JIT compilation. Interpretation in the traditional sense is a switch/case loop, i.e. the code being interpreted is never translated all the way into a block of native code for direct execution, it's instead.... interpreted (there's no better word for it).

The word 'compiler' does not necessarily mean 'ahead of time'. Compilation can be applied ahead-of-time, or just-in-time. It's compilation either way.

You could argue that JIT compilation is a way of accelerating an interpreter. I don't like this use of the term. For that matter, neither does Sun: it's why they went with 'virtual machine', as the implementation might use compilation, or might just be an interpreter.

What difference does it make if the step which interprets the bytecode is executed as bare hardware or slower software? All software can be converted 1:1 to hardware.

Well... whatever. How things work in the real world is that the graphics driver generates code in the ISA of the GPU, which the GPU then executes.

We won't see LLVM-in-hardware, for the same reason we don't see Java-in-hardware. Software compilers work well, and allow for hardware that's aimed at being really fast, not at accepting some inappropriate ISA. Also, that hardware wouldn't play nice with other APIs like Direct3D.

Re:Uh, what?

[Anonymous Coward]

That is what is interesting about Vulkan, it doesn't specify a shader language, per se, only an intermediate representational format all drivers are required to support. In this case, they are reusing the Intermediate Language they were already using for OpenCL, SPIR-V.

This has several benefits.
1. Now, ALL shaders will have to be compiled to this format, and the drivers will take care of the caching.
2. You can use OpenCL to create shaders. Or GLSL. Or HLSL. Or C. Or D. Or ..... you get the idea.
3. Simply create a compiler that translates these languages to SPIR-V, and you have a shading language.
4. SPIR-V is based on LLVM's IL, therefore it should be relatively trivial to create compilers to this representation. You won't have to start from scratch.

Re:Uh, what?

[Wootery]

To be fair, one might continue to use the word 'interpreter' even if the program uses JIT-compilation, as the only other term we have for such programs is 'virtual machine', which can be confusing.

The proper description of a modern JVM would be something like a software implementation of a Java bytecode machine which uses both interpretation and JIT-compilation, in mixed-mode execution.

'Interpreter' has two definitions, I guess. This isn't to say that shaitand's original comment uses the term correctly, though: when we're talking gory details of a build system, 'interpret' is only used to refer to the more precise of its two definitions, i.e. something like a switch/case-based interpreter.

And of course, shaitand is utterly mistaken to put:

The only difference between a compiler and an interpreter is when they perform compilation.

Re:Uh, what?

[exomondo]

This would do exactly the opposite. You don't compile bytecode, you compile to byte code. The entire point is that byte code is interpreted at runtime.

So it isn't the opposite, a compiler (this may be a JIT compiler) most definitely is needed. And no, it is not necessarily interpreted at runtime, for example - and I'll use LLVM because since SPIR-V was based on LLVM - how do you think you get from C++ code to native code through Clang/LLVM? Yes bytecode is generated but it isn't interpreted at runtime. Just because there is a bytecode step doesn't mean it is interpretted at runtime, so what makes you believe Vulkan is going to use JIT compilation (rather than compiled ahead of time)?

Vulkan would be the one to provide a compiler.

How can "Vulkan" provide a compiler for every GPU architecture? You mean Khronos or the IHV implementation of Vulkan (which would of course be part of their vulkan driver). It makes sense for the driver for a particular architecture to provide the compiler for that architecture, where else would the compiler come from?

Re:Uh, what?

[exomondo]

It strikes me that when you said "Vulkan would be the one to provide a compiler" that you may not have meant the one that compiles ahead-of-time or JIT compiler that compiles the bytecode to machine code and that perhaps you meant the compiler that creates the SPIR-V code. If that's the case then why would "Vulkan" or Khronos or the IHVs provide the compiler? This is a compiler that creates SPIR-V code from ... well pretty much any language, so why would "Vulkan" provide this compiler?

Re:Uh, what?

[TheRaven64]

This is a confusion in terms. Personally I blame Sun. An interpreter IS a form of compiler, it is the term used to refer compilation at run time

No, sorry. A compiler is, in theoretical terms, a partial application of an interpreter to a program. In practical terms, a compiler transforms the input into some other form, which is then executed, whereas an interpreter executes the input directly. JIT compilation is still compilation. A just-in-time compiler is the term given to compilers that produce their output just before it is executed, as opposed to ahead-of-time (AoT) compilers, which produce it all up front, even if some paths are never executed.

There's some complication, because most environments that do JIT compilation also include interpreters that gather profiling information to incorporate into the JIT compiled code and to improve startup times. JavaScript implementations, in particular, often spend a reasonable amount of time in the interpreter because most web pages contain a load of JavaScript that's only run one or two times and the time taken to compile it is more than the time saved to execute it. Some have multiple compilers - JavaScriptCore from the WebKit project has an interpreter and three different JIT compilers that have different points in the space between compilation time and execution time - they'll recompile hot paths multiple times as they're executed more, with more optimisation each time. The key difference between the interpreter and compilers here is that the compilers are each invoked once on a segment of code and it's then executed without involving the compiler. The interpreter is involved every time the bytecode is run. It reads a bytecode and then jumps to the segment of interpreter code that executes it and then returns. The compiler takes a sequence of bytecodes, generates a fragment of native code to execute them, and then this fragment is combined with other fragments to produce a running program.

The shader compilers in drivers, however, are not JIT compilers. They are AoT compilers that are invoked at load time - often at install time. They don't compile the code just before it's run, they typically compile it once and cache the result for multiple invocations of the program. Some drivers (Windows and Android come to mind) have a mechanism that allows you to do the compilation at install time. Unlike most JIT environments, graphics drivers don't tend to use run-time profiling for optimisation, the bytecode exists solely for the purpose of providing an ISA-neutral distribution format.

Re:Uh, what?

[shaitand]

"Well... whatever. How things work in the real world is that the graphics driver generates code in the ISA of the GPU, which the GPU then executes.

We won't see LLVM-in-hardware, for the same reason we don't see Java-in-hardware. Software compilers work well, and allow for hardware that's aimed at being really fast, not at accepting some inappropriate ISA. Also, that hardware wouldn't play nice with other APIs like Direct3D."

If the ISA of the GPU is byte code what stops the Direct3D SDK from generating it? It is the byte code and not LLVM I'm suggesting be implemented in hardware. A common instruction set similar to x86 in CPU land and just like in that space it only exists as a public interface that is then translated into optimized intel or AMD underlying magic on the chip almost immediately.

Or rather, an API agnostic open specification byte code that all API's can target. The benefit is obvious, if intel, amd, and nvidia all implement native hardware support for a common instruction set it not only provides a compatibility blanket that dramatically simplifies building better API's but it also dramatically simplifies producing drivers for their hardware.

Re:Uh, what?

[zapadnik]

There was Java-in-hardware on phones in the past. Please Google it.

All you folks are talking about how Direct3D works. OpenGL GLSL works differently and you compile from source directly for you hardware at runtime (usually propgram startup, but can be while the program is running). I know, I do GLSL every day and OpenGL is awesome for this - you get REPL-like functionality where you can edit a shader, recompile and re-link the shader program and have it apply the next frame. It is fun to give demos where you have a MiG-29A flying along, edit the shader and apply it while the aircraft is still moving and doesn't miss a beat (the GLSL shader compillers are really, really fast). I've not looked at the Vulkan API but it'll be a step backward if it loses this capability (which Direct3D is also missing).

OpenGL?

[MrL0G1C]

OK so I decided to break with protocol and RTFA. Vulkan is what the makers see as being the next generation of OpenGL and it is backed by Valve for obvious reasons. It is aimed at a wider range of device types.

Re:OpenGL?

[Megol]

And AMD, Nvidia, Intel, Samsung, EA, Apple, ...

Re:OpenGL?

[Dishwasha]

It is aimed at a wider range of device types.

Thank god. It's about time my ThinkGeek USB hotplate be accelerated with voxel heating.

Re:OpenGL?

[Anonymous Coward]

Yeah right.

AMD and Nvidia _like_ API fragmentation. "Mantle", anyone? "How it's meant to be played", anyone? (i.e. Nvidia's "we'll help you optimize your game especially for our subtly different opengl flavor").

Don't get me started on the the mobile vendors (ARM and PowerVR) - They seem be be fixated on highly platform specific drivers just like the bad old days before the IBM PC brought a semblance of interoperability.

This new API will get a bit of uptake, probably from AMD and one or two of the mobile vendors (although their support will be closed source, closed platform, and probably only ever work properly on a development board), and then it'll die a quiet death, just like Mantle is already doing..

Re:OpenGL?

[Kjella]

They've come full circle:
1. AMD announces Mantle, a low level graphics API which may give consoles an edge over the PC.
2. Microsoft panics and announces DirectX 12, aiming for pretty much the same thing.
3. Khronos Group panics and announces OpenGL Vulcan, aiming for pretty much the same thing.
4. AMD announces there'll be no public SDK of Mantle, use OpenGL/DirectX.

So in the end we'll probably have feature parity again. How important it is remains to be seen, outside of drawcall benchmarks it's unclear how much real world difference it makes, what is certain is that it exposes a lot more of the complexity to the developer. That of course gives you more room to optimize, but it remains to be seen how many will be able to take advantage of it.

On the bright side, it might actually mean there's less code that needs to be written and that open source might catch up a bit, it says it'll run on top of all platforms that support OpenGL ES 3.1 which might become a much bigger goal than OpenGL 4.x.

Re:OpenGL?

[Anonymous Coward]

so..there was so much infighting, vendor specific extensions, & death-by-committee that they are abandoning OpenGL to start an all new Open Graphics Layer.
It's like the simpsons episode where they move the town down the highway.

Re:OpenGL?

[HornWumpus]

Get out! We don't like FA readers around here.

Re:OpenGL?

[Megol]

"Working group participants" - or in other words those that actually works on the Vulkan specification. A step further than "just" supporting it.

Tachyon option nixed.

[Mal-2]

It was initially intended to use Tachy-tech(TM) but despite the incredible speed boosts, they were unable to deal with the issue of all frames being rendered 1.47 microseconds in the past.

Vulkan vs. OpenGL ES

[Misagon]

Imagination Technologies (PowerVR) posted this today with more in-depth info:
http://blog.imgtec.com/powervr...

The purpose of Vulkan is apparently to be a low-level alternative to the high-level APIs OpenGL and OpenGL ES.
Game consoles such as the Playstation series have had both high-level and low-level graphics API:s for many years. Using the low-level API means that you can squeeze out more performance, perhaps at the expense of more developer time. The application takes over more duties, such as resource management etc.
If your app is a game, then your resource management and shaders are often pretty much static anyway.

Re:Vulkan vs. OpenGL ES

[Anonymous Coward]

It won't be a "low level alternative". It will be THE alternative in the future. Nobody's going to want to continue supporting 4.5 and older OpenGL drivers into the future. It's a big enough headache for them already. I expect glNext ("Vulcan" or whatever it is) to be the only game in town 3-4 years from now.

Re:Vulkan vs. OpenGL ES

[Wootery]

You mean along with Direct3D?

Re:Vulkan vs. OpenGL ES

[91degrees]

Windows still has 90% market share on the desktop. I imagine D3D will keep going for a while.

PowerVR?!??!?

[BenJeremy]

Competing GPU APIs... PowerVR... it's like it's 1998 all over again!

Does this do tile-based rendering?

Re:PowerVR?!??!?

[91degrees]

Does this do tile-based rendering?

I presume you intended this as a joke, but from the OpenGL/Vulkan comparison table in the overview: "Matches architecture of modern platforms including mobile platforms with unified memory, tiled rendering"

On that point - I'm not all that sure exactly what it does to support tiling. The PowerVR blog says "A render pass consists of framebuffer state (other than actual render target addresses), and how render targets should be loaded in and out of the GPU at the start and end of each render. This structure is the key object that allows tiled architectures like PowerVR to run at extremely high efficiency." but that it's not really all that clear to me how this makes a difference.

Re:PowerVR?!??!?

[Misagon]

PowerVR is the #1 GPU on mobile phones and tablets. For instance, all Apple iPhones and iPads have had embedded PowerVR GPUs in their SoCs.

Necessary link

[watermark]

Necessary link http://xkcd.com/927/

Re:Necessary link

[exomondo]

Necessary link http://xkcd.com/927/

How does that apply here? The yet-to-be-released Mantle is AMD-specific (or at least to get the most out of it you need GCN architecture which is AMD-only), Metal is Apple-specific, DirectX 12 is Microsoft-only (and thus far seems to be exclusive to Windows 10) so the only actual one that is a platform and vendor -agnostic specification here is Vulkan.

Re:Necessary link

[exomondo]

OpenGL comes to mind

No, OpenGL (maintained by the Khronos Group) suffers from the problems that Mantle, Metal, DX12 and Vulkan (also maintained by the Khronos Group) exist to solve. Vulkan is the future of OpenGL.

Sole purpose of FOSS

[jader3rd]

So if Microsoft wasn't coming out with something, nobody would be creating a FOSS project to solve that problem? It does seem like many FOSS projects exist for the sole purpose for having an alternative to a Microsoft product.

Re:Sole purpose of FOSS

[phorm]

There are a couple things that tend to breed innovation/change. One is a driving need. The other is competition.

Re:Who the heck is "Khronos Group"?

[91degrees]

Khronos is the organisation responsible for the OpenGL standard amongst other things.

And why should I care?

No idea. Perhaps you don't. If you're into 3D graphics then you will care. If you don't care then that's up to you. The implication here that we think you should care is a little childish. If you don't care that's fine. Find something you do care about.

Re:OpenGL lowest common denominator

[Cyberax]

1) Vulkan does away with OpenGL state so it's easy to wrap.
2) It exists, see: piglit ( http://piglit.freedesktop.org/ ).
3..5]) Good idea.