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

[Anonymous Coward]

It will be a Windows 10 thing but not a "Windows 10 hardware" thing. Microsoft are going to offer free upgrades for everyone who has Windows 7 and 8 to Windows 10 anyway, and DX12 won't need the latest graphics card in order to function unlike previous iterations. AFAIK DX12 will work with DX10 capable cards.

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

[Anonymous Coward]

I just hope that their claims of 70% efficiency over DX11 are true. Going from DX9 to DX11, there is definitely a performance boost, so if DX12 can go further it will breathe new life into some older systems.

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

[Anonymous Coward]

Uhh, yes. Companies don't want people who exhibit no initiative or ambition.

I'm not surprised you're unemployable.

Re:Boy you know you're old

[Anonymous Coward]

Oh noes! It will require a video card that was made within the past five years!

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

Re:Boy you know you're old

[Anonymous Coward]

Don't worry, it is very likely that DX12 will indeed have 70% of the efficiency of DX11.

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]

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

JIT compilation, An interpreter is a run time compiler, nothing more, nothing less. JIT compilation is a form of interpretation. No modern interpreter sits and converts to native code line by line during execution, they COMPILE to native code at runtime and then execute that. The only performance benefit of compilation vs interpretation is start-up time once executing compiled code is not necessarily faster. The perl interpreter is a good example. People tend to suck at writing fast perl code but someone who actually understands the language can write a perl solution that will rival or beat a C implementation for most solutions. You can compile perl implementations to native binaries and the interpreter typically compiles to an intermediate byte code, you can compile to that byte code in advance as well and run that with the interpreter in the same way you run java byte code on it's interpreter aka the java virtual machine. The only reason we do the byte code thing at all is that it's a machine code for an imaginary machine that is extremely efficient to interpret.

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

Bytecode is the native machine code language of an imaginary machine, when I say native execution I mean alter the GPU to speak that machine code as it's native instruction set... in the silicon.

An interpreter is a form of compiler that is runs at runtime rather than in advance, JIT compiler is a form of interpreter design, and cloud computing is just the current evolution of clustered computing plugged into an internet connection and clusters in turn are nothing more than the distributed computing platforms built before them. You can make up new words all day long but lets stop pretending these things are NEW are not just the progressive realization of computing concepts that were invented in the 50's. Now get off my lawn.

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?

[Anonymous Coward]

Here SPIR is not a byte code like java have. It is an intermediate representation as explicitly stated https://www.khronos.org/registry/spir/ go read the specification. There is no way in hell anyone will converge on a common bytecode because GPU is all about tradeof and there is different tradeof depending on what is your target (power consumption, raw power, texture oriented, compute oriented ...).

Each GPU designer choose different tradeoff and often offer different product line with different tradeof. This tradeof translate into many hw parameters being different. Like the number of registers available, the way texture informations is provided to texture unit, the way loop, conditional and other control structure are implemented...

So it is very much obvious to anyone in the industry and to many folks following this from afar. That there is no way to converge toward a unified byte code.

Thus clearly your statement and understanding is wrong. SPIR need to be compiled to the specific GPU target and this compilation might involve complex optimization phase to match the program to the hw specificity.

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?

[Anonymous Coward]

Also, the bytecode/IR is not LLVM based: https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf

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]

It looks a lot like an intermediate language, except it's platform-neutral, which is good, but it's binary, which, in my opinion, is bad. I would have preferred something like LLVM's IR, which is readable. Bytecode is more compact, but what's the point if you're just compiling it anyway.

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

Re:Uh, what?

[Anonymous Coward]

Yes, except note that SPIR-V is a new IR. SPIR-V broke away from reliance on LLVM's IL. It is self-contained and standing on its own. Check out the SPIR-V materials out there, e.g. https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf or http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv&num=1 which mentions "the Khronos Group has a work-in-progress item of putting out a SPIR-V to LLVM IR pass that would convert this OpenCL and Vulkan code representation into LLVM IR."

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?

[Anonymous Coward]

I just saw a bunch of logos with no clear indication of who is supporting what.

Re:OpenGL?

[Anonymous Coward]

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

Mantle is dying because it's AMD specific like Glide and other shit from the past. More specifically, DirectX 12 devoured Mantle's functionality into mainline DX making Mantle unnecessary on Windows.

Vulkan is essentially nothing more than OpenGL's DX12, it is what you get when you absorb Mantle into OpenGL.

I doubt those other vendor's are as happy with the status quo as you claim, current OpenGL is complicated on the driver side, even more so if you want your implementation to actually perform well. Vulkan is significantly simpler on the driver side by pushing all the complex work upwards into the application, I suspect it will be smaller programmers who are not using a professional engine that are going to be the most unhappy about this.

Re:OpenGL?

[Anonymous Coward]

AMD made Mantle because Microsoft and Khronos Group were being lazy bastards. AMD said one of two things will happen, Mantle will take over or someone else will make something that will, either way the supported both outcomes. Prior to Mantle, both Microsoft and Khronos stated they had no intentions of making a new API.

Mantle put a fire on their asses and that's all it was meant to do.

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.

Re:OpenGL?

[Anonymous Coward]

Not want to break your party, but DX12 was started way before mantle saw the light.

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.

Learn to spell.

[Anonymous Coward]

Then we'll talk.

Re: Learn to spell.

[Anonymous Coward]

Was haben Sie gegen >>Vulkan?

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

[Anonymous Coward]

Assuming Apple aren't going to implement a D3D layer into iOS and Android devices aren't going to start running WINE, yes.

Re:Vulkan vs. OpenGL ES

[91degrees]

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

Re:Vulkan vs. OpenGL ES

[Anonymous Coward]

It will because Microsoft have a great toolset and richer ecosystem for developers and because driver writers tend to put a lot more man hours into D3D drivers on the desktop than they do OpenGL drivers. The pressures on the downside are the fact that Microsoft don't have much market share away from the Desktop, where the majority of devices that want to do graphics are.

However I will say this: D3D 12 and glNext represent a kind-of convergence in terms of APIs, so I expect it to be much, much easier to interchange them. That is to say, the abstraction allowing you to choose either one on desktop will be a lot thinner than it needs to be today.

PowerVR?!??!?

[BenJeremy]

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

Does this do tile-based rendering?

Re: PowerVR?!??!?

[Anonymous Coward]

The iPhone 6 etc. have good standing on the market...

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

[Anonymous Coward]

It's only necessary if it hasn't been posted on every article for the last week. Which it has.

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

[Anonymous Coward]

OpenGL comes to mind

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:Sole purpose of FOSS

[Anonymous Coward]

Not sure what your point is. The Khronos Group isn't a FOSS organization, and OpenGL isn't a FOSS project.

Re:Sole purpose of FOSS

[Anonymous Coward]

Because Open Sores isn't a creative group.

Who the heck is "Khronos Group"?

[Anonymous Coward]

And why should I care?

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.

oh boy

[Anonymous Coward]

I'm still playing emulators; Mame, nestopia(currently playing zelda 2),fusion,magicengine, snes9x, pcsx, pcsx2, dolphin. Because they are enjoyable. The sad thing the pc needs mantle and directx12 to push the graphics even further for the graphical whores and this is what has become of PC Gaming. I can't believe how ppl put down forza horizon 2 and driveclub because it's not on par with the pc graphics even though these games look far beyond amazing.

OpenGL lowest common denominator

[Anonymous Coward]

Having spent the last 1.5 years writing a from scratch openGL 3.2 forward profile application for a large user base of 3 year old or newer machines (thus the 3.2+ and not 4.x OpenGL usage), I can tell you it is a step above a K&R style c api and a step below an ANSI C api and has a 1995 air to it.

Combine with the web search misdirection from a large number of dead, near dead and zombie C++/C wrapper frameworks, v2.0 tutorials, and v2.0 blog posts; and one gets a nice extended stretched out OpenGL learning curve.

Khronos group - 1. Create simplistic API with a C interface and a lightweight object based .NET/Java interface, 2. Create a test suite for both 2D and 3D for the new API including reading back pixels from the framebuffer to compare to a known good answer, 3. Create a simple 3D jump start application in C and a .NET/Java version, and 4. Create a simple 2D jump start application in C and a .NET/Java version. 4. Ensure that the jump start applications respond to zoom, pan, rotate, change viewport aspect ratio/size, etc. 5. Ensure that the jump start applications have a shader with basic phong shading for 3D and textures for both 3D and 2D.

Freeglut, OpenTK, etc. provide function by function OpenGL wrappers and little else. OpenGL needs an endorsed by the Khronos group set of sample applications.

Valve/AMD/Nvidia could logically proposed their own API to avoid all of the OpenGL legacy code/functionality....

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.

SPIR-V is not "LLVM-based bytecode"

[Anonymous Coward]

Checking out the materials (https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf) SPIR-V is a new thing, defined by Khronos, not the previous SPIR based on LLVM. (But they'll be converters.)