Khronos Group Announces Vulkan To Compete Against DirectX 12 91
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."
let me guess, ideal hardware found indicator (Score:4, Funny)
a Tribble purr?
Re: (Score:2)
No, that sound is reserved for errors in the accompanying physics engine, Cling1.
Re: (Score:2)
Boy you know you're old (Score:3, Funny)
when the only words in that headline you know are "group announces" and "compete against"...
Re:Boy you know you're old (Score:4, Informative)
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/... [anandtech.com]
Re: (Score:2)
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: (Score:2)
That and your clear disdain for self-education using the bountiful resources of the internets.
Re: (Score:2)
Hahahahahahaha1!!!!!1 LOL you think that impresses anyone when hiring????
Oh my God!!!!
Re: (Score:2)
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: (Score:2)
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: (Score:3)
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 M
Re: (Score:2)
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
Re: (Score:2)
2) It exists, see: piglit ( http://piglit.freedesktop.org/ [freedesktop.org] ).
3..5]) Good idea.
Re: (Score:2)
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: (Score:2)
Are you on the right site?
Re: (Score:1)
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 as
Re: (Score:2)
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".
Uh, what? (Score:3)
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: (Score:3, Insightful)
Re: (Score:2)
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 contex
Re: (Score:2)
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: (Score:2)
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. J
Re: (Score:2)
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 co
Re: (Score:2)
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? I
Re: (Score:1)
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 whe
Re: (Score:2)
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 exec
Re: (Score:1)
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 a
Re: (Score:2)
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: (Score:2)
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 [slashdot.org] uses the term correctly, th
Re: (Score:2)
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 tran
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:1)
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. ..... you get the idea.
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
3. Simply cr
Re: (Score:2)
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 bi
Re: (Score:2)
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: (Score:2)
s/assembly/binary/
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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 th
Re: (Score:3)
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
OpenGL? (Score:5, Informative)
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? (Score:4, Informative)
And AMD, Nvidia, Intel, Samsung, EA, Apple, ...
Re: (Score:1)
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 ven
Re:OpenGL? (Score:4, Interesting)
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: (Score:2)
"Working group participants" - or in other words those that actually works on the Vulkan specification. A step further than "just" supporting it.
Re: (Score:3)
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: (Score:1)
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: (Score:2)
Get out! We don't like FA readers around here.
Tachyon option nixed. (Score: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 (Score:2)
Imagination Technologies (PowerVR) posted this today with more in-depth info:
http://blog.imgtec.com/powervr... [imgtec.com]
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
PowerVR?!??!? (Score:2)
Competing GPU APIs... PowerVR... it's like it's 1998 all over again!
Does this do tile-based rendering?
Re: (Score:2)
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 [imgtec.com] 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
Re: (Score:2)
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.
Re: (Score:1)
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: (Score:2)
You mean along with Direct3D?
Re: (Score:1)
Necessary link (Score:2)
Necessary link http://xkcd.com/927/ [xkcd.com]
Re: (Score:2)
Necessary link http://xkcd.com/927/ [xkcd.com]
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: (Score:2)
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 (Score:2)
Re: (Score:1)
There are a couple things that tend to breed innovation/change. One is a driving need. The other is competition.
Re: (Score:1)
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.