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?

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

[Cederic]

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

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.

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?

[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?

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

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?

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