Vulkan to be shown at GDC

[Humbug]

So the session is scheduled for March 5th (Thursday) 10am

http://schedule.gdconf.com/session/glnext-the-future-of-high-performance-graphics-presented-by-valve

Hopefully it will show up on youtube soon after.

 

AMD's Robert Hallock has written a cryptic blog post about mantle which includes the below quote

Mantle’s definition of “open” must widen. It already has, in fact. This vital effort has replaced our intention to release a public Mantle SDK, and you will learn the facts on Thursday, March 5 at GDC 2015

http://community.amd.com/community/amd-blogs/amd-gaming/blog/2015/03/02/on-apis-and-the-future-of-mantle

 

He may be referencing the presentation on March 5th by Valve about the new OpenGL (Vulkan) and he may be claiming credit to AMD by implying that it was largely shaped by handing over Mantle to Khronos. He is effectively saying don't expect the Mantle SDK, instead watch for what happens on March 5th...

[Linus_torvalds]

Yay for not needing to downgrade from an 8320 to an i5 due to poor game multithreading

are you sure that it is downgrade?

 

i5 4690k will blow out of the water that shitty 8320 witch is bottleneck even on 4.7 GHZ with GTX 660 ti.

[Humbug]

A bit more info from Phoronix

• Working drivers will only be available at the end of the year (I guess Dice, Valve and co have got access to very early builds in order to do the GDC demo).

• SPIR-V is the cross-API intermediate language for parallel compute and graphics to represent both OpenCL and Vulkan source languages. There's full flow control, graphics and parallel constructs, and other additions to its IR over the original SPIR.

• Provisional specification to OpenCL 2.1 is being released, and SPIR-V is set to make its debut as the IR for both Vulkan and OpenCL 2.1

• Neil Trevett (Nvidia) confirms that on the mobile side Vulkan should work with all OpenGL ES 3.1 hardware and newer

• While supporting Vulkan will be a greater burden for Mesa/Gallium3D driver developers, Vulkan drivers will be simpler than OpenGL drivers. The simpler drivers should lead to better cross-vendor portability, lower-overhead, etc.

• The Khronos Group and its members are also working on an open-source conformance test suite to provide unit testing of all Vulkan functionality to ensure correctness. This should help avoid uncertainties between drivers over correct behavior, lead to better driver testing

• Vulkan also features a layered architecture so there's validation and debug layers that can be dynamically loaded only when needed. Vulkan provides direct GPU control, is designed to be cross-platform, and will be more multi-threading friendly while being a simpler interface.

• Valve and LunarG among others are working on tools for the loadable debug/validate layers of Vulkan

http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv&num=2

http://www.phoronix.com/scan.php?page=news_item&px=SPIR-V-Initial-Spec

 

clicky below

 

Some points from PowerVR blog

• PowerVR have already started playing with Vulkan internally using alpha drivers ( just porting one of their OpenGL ES 3.0 demos to the new API)
• the application has direct, predictable control over the operation of the GPU.
• Vulkan interface is designed to be as close to the architecture of modern GPUs as possible. This means that both the code size and the amount of work going on in user and kernel space for the Vulkan driver is very small and therefore will be more efficient than OpenGL ES.
• the number of instructions in the front end portion of the driver is significantly reduced compared to OpenGL ES. This reduction in complexity enables developers to issue more draw calls, while hardware vendors can achieve better stability and quicker driver bring up time.
• hope that Vulkan should eventually be very stable because there is less code to go wrong.
• high level management of the GPU needs to be performed by the application (e.g. resource lifetimes). The driver is almost completely hands-off  and does what the application tells it to.
• While the above results in greater complexity in the application, it should be offset by the need to work around the driver (e.g. shader pre-warmings in OpenGL ES). If your application is using an engine to do the rendering, the engine will probably already be managing this anyway, and Vulkan can provide an almost free speedup.
• the API will make programming 3D graphics much more predictable.

• Command buffers can be created on a different thread to the thread they are submitted on. This means rendering commands could be created on all cores of a CPU.There is no extra work or locking required to do this – a feature that was not previously possible with OpenGL ES. This may be of use to games which need to recreate their render commands a lot (e.g. Minecraft)

http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

[Humbug]

Looks like Intel already has working drivers and is showing it off in comparison to openGL

https://twitter.com/MichalZiulek/status/573172201450434560

 

Below pdf has a screenshot of a debugger showing DOTA 2 running in Vulkan which suggests that's part of the long-term plan in moving the game to Source 2.

https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf

 

[Humbug]

A look at some of the debugging tools which appear to be in a surprisingly advanced state, and looks like Valve already has Dota 2 running internally on Vulkan with source 2.

http://youtu.be/miZmas6sGqM

[Humbug]

http://www.youtube.com/watch?v=EUNMrU8uU5M&sns=em

Also

http://m.ustream.tv/recorded/59557323?rmalang=en_US

[Opcode]

I dont like open GL at all sorry

 

Most AAA games that use open GL are on idtech an they are a mess ( evil within ,RAGE).

But... But... the Linux gaming...

[Valentyn]

I dont like open GL at all sorry

 

Most AAA games that use open GL are on idtech an they are a mess ( evil within ,RAGE).

Going by that you shouldn't like DX either, considering there are far more games that are messes using it, especially from the likes of Ubisoft. EA, and others.

 

Blame the engine, and developers, not the API. Especially since in the professional world OGL is the king, where DX is in the minority. It depends on how it's used.

 

I strongly welcome OGL Next, and I hope the competition is going to be at the levels of late 90's early 2000's again.

[Humbug]

Highly recommended watch below. Lots of great info in there about Vulkan and the state of the graphics industry.

 

http://www.gdcvault.com/play/1022018/

[Humbug]

Google has officially announced their support today on Anroid

It was always expected but it's still good to hear because that means millions and millions of devices get Vulkan and loads of developers get familiar with it.

 

As mentioned previously Vulkan will be one common API not only across multiple desktop and console (potentially) OS but also down to mobile OS. This raises the question of how one API can utilize the capabilities of high end desktop GPUs as well as mobile low power parts. The below is a useful explanation from anandtech about the feature sets which are basically classes of hardware for developers to target.

 

Due to the factors that resulted in the creation of OpenGL ES, this was never a huge problem for either branch of OpenGL since each could be scoped as appropriate and integrated separately. However with Vulkan there is now just one API, and such a coarse approach would imply limiting Vulkan to just the features mobile GPUs could support, or making even more extensive use of extensions.

 

To that end, today Khronos is announcing that Vulkan will support defined feature sets in order to help simplify application development and to more readily support mobile and desktop hardware under the same API. Feature sets, as implied by the name, will be groupings of features that will be advertised under a single feature set name, with the idea being that developers will build their programs against a handful of feature sets instead of a massive combination of individual extensions or capability bits (though developers can still use individual features if they’d like). Feature sets are nothing new to desktop graphics, with Microsoft’s DirectX standard having supported them since DirectX 11 in 2009.

While Khronos is announcing that Vulkan will support feature sets, they are not announcing the individual feature sets, and for good reason. In traditional Khronos consortium fashion, Khronos is going to leave the feature set definitions up to the platform holder rather than define those sets themselves. This means that it will typically be the OS developer defining the feature sets, as will be the case on Android. However because Khronos is leaving this up to the platform holder, for holders who opt not to define feature sets for their Vulkan-enabled platforms, Khronos will step in and define those feature sets. In other words platform holders get first dibs, but either way someone will take on the task of defining the feature sets.

Practically speaking, this means that while Android’s feature set will be defined by Google and one can expect SteamOS’s to be defined by Valve, Windows’ feature set will be defined by Khronos. Microsoft is a member of the Khronos consortium and could define it, however Microsoft has taken a hands-off approach on Khronos’s graphics APIs in recent years – presumably in favor of focusing on DirectX – so we’re not expecting to see Microsoft make those definitions.

 

http://www.anandtech.com/show/9509/vulkan-status-update-will-use-feature-sets-android-support-incoming

 

[Humbug]

And below we have the first publicly shown footage of Vulkan running on android. This is a comparison with the existing standard for android which is openGL ES 3. This is from Imagination tech. The demo is called Gnome Horde and runs under Android on the Intel-based Nexus Player, a consumer device integrating a PowerVR G6430 GPU

 

On the left is Vulkan, on the right is current openGL ES

 

Using Vulkan we batch draw calls into tiles and render a tile at a time. Each time a tile goes out of view, comes in to view or changes its level of detail we regenerate a command buffer (more on this later). By avoiding changes in the command buffer, we reduce overall CPU usage significantly. In OpenGL ES, all draw calls are submitted dynamically according to the tiles in view, with no opportunity to cache draw calls that have already been executed.

 

As you can see from the CPU usage graph in the bottom left of the video, CPU usage is very low for this many draw calls in the first mode. The lower line is the process CPU usage and the top line represents system CPU usage. Both are reduced in Vulkan due to the ability to process command buffers before submission.

In the highest zoom level we are drawing around 400,000 gnomes (and other objects) per second. Each object has a different transformation, and there are many different materials, textures, blend modes and shaders being used. The reason that the OpenGL ES API struggles with these tasks is because OpenGL ES requires many calls into kernel mode to change the state of the driver, along with validating that state and any extra work that goes on behind the scenes, all during an applications render loop. This is in contrast to Vulkan where we can pre-generate these commands. Executing pre-generated commands in Vulkan is very fast, with little CPU overhead and no need for the driver to validate or compile anything inside the render loop. These pre-generated commands are called command buffers.

 

Command buffer re-use

 

Being able to re-use command buffers proves useful in some circumstances. This feature will not be a panacea, but it will be possible to use it to a great extent in many games and applications. In this specific instance we decided that being able to re-use command buffers for each tile would reduce the overall CPU usage.

Before drawing in both APIs, the driver needs to compile a set of commands for the GPU to execute, validate those commands, and do other work – all before actually starting the GPU. With OpenGL ES, this needs to be performed for each draw call, during the render loop. In Vulkan we can compile and validate this list of commands ahead of time, and then have the GPU execute these pre-generated commands.

 

Parallel command buffer generation

 

In the next demo modes, watching the CPU graph we can see that we can go from very little CPU usage to using nearly the whole of every CPU core. What’s happening here is the camera is moving much faster and therefore needs to regenerate command buffers more frequently (a slightly unrealistic use-case). In OpenGL ES we are CPU bound and cannot feed the GPU with enough commands. However with Vulkan we have the opportunity to distribute the regeneration of the tiles command buffers to different threads. This is not possible with OpenGL ES which was designed before multi-threading was widely available. In a real application, the workload will be somewhere between the two extremes of dynamic draw calls and static draw calls.

In this case we are sacrificing CPU usage for memory usage. We could store all of the command buffers for the entire scene in memory. However on mobile devices, memory is often limited so we only store the command buffers that are in the viewable frustum instead. With Vulkan we are purposefully bound by GPU performance which goes to show that we are using the the CPU effectively and feeding the GPU with enough commands.

 

For equivalent performance, the Vulkan demo could have the CPU run at a much lower clock frequency, increasing efficiency and battery life compared to OpenGL ES.

In this mode there are roughly 80 command buffers being re-created each frame distributed between the cores of the CPU. Each command buffer has 45 draw calls and other state setting information. With all this work going on, it is good to see the frame rate stays the same as in the previous mode.

 

Memory allocation strategies

 

One advantage of Vulkan over OpenGL ES is that the developer has more visibility of the memory that needs to be allocated. With OpenGL ES the driver handles most of the allocation and hides it away from the developer. With Vulkan the memory that the driver allocates is very minimal and the developer can use different memory allocation strategies. For example, if an image is not in use by the GPU, the developer could decide to use that memory for other purposes like uploading a texture.

http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

[martlart]

Google has officially announced their support today on Anroid

It was always expected but it's still good to hear because that means millions and millions of devices get Vulkan and loads of developers get familiar with it.

 

As mentioned previously Vulkan will be one common API not only across multiple desktop and console (potentially) OS but also down to mobile OS. This raises the question of how one API can utilize the capabilities of high end desktop GPUs as well as mobile low power parts. The below is a useful explanation from anandtech about the feature sets which are basically classes of hardware for developers to target.

 

http://www.anandtech.com/show/9509/vulkan-status-update-will-use-feature-sets-android-support-incoming

Shouldn't this be in a thread of its own?

[Trik'Stari]

Please let this be equal to DX12 so I can switch to Linux instead of W10

[Exty]

Why are you hyped about this? its 7 months away from now... 7

yeah .... no

[othertomperson]

Lots of baffling things said so far.

 

Such as the fear that Nvidia won't support it. People are worried about Nvidia, a company that has spend an arse-tonne of money on three separate Android gaming platforms not supporting the only new API that supports Android.

 

Such as people thinking that Linux gaming is dying when it's growing faster than it ever has, at a time when a cross platform competitor to Directx is actually useful given the amount of gaming on non-x86 architectures now AND the fact that this time this API actually seems to rival Directx.

[Humbug]

Lots of baffling things said so far.

Such as the fear that Nvidia won't support it.

Who said that? NVIDIA always came on board with khronos standards. Also Neil Trevett the president of Khronos is an NVIDIA employee.

They even gave a talk on Sunday about vulkan on NVIDIA

http://s2015.siggraph.org/attendees/nvidia-best-gtc-talks

[othertomperson]

Who said that? NVIDIA always came on board with khronos standards. Also Neil Trevett the president of Khronos is an NVIDIA employee.

They even gave a talk on Sunday about vulkan on NVIDIA

http://s2015.siggraph.org/attendees/nvidia-best-gtc-talks

 

 

I can see glNext being widely accepted, especially in cross-platform titles, since all big players stands behind it, unlike Mantle - if it doesn't get accepted by NVidia, I don't see a bright future for it.

 

[DaRk0]

No idea why I'm being quoted here, since I never said NVIDIA won't support Vulkan.

[Guest Strangerbob]

Steam OS

-that has the UI as win7

-MS office applications work on

-all games work on, regardless of API through translator or whatever

 

 

Until then i dont see myself using anything else besides WIN7.

[patrickjp93]

Who said that? NVIDIA always came on board with khronos standards. Also Neil Trevett the president of Khronos is an NVIDIA employee.

They even gave a talk on Sunday about vulkan on NVIDIA

http://s2015.siggraph.org/attendees/nvidia-best-gtc-talks

Nvidia has been behind OpenCL since the beginning though.

[Humbug]

Nvidia has been behind in OpenCL since the beginning though.

True. Because of CUDA?

 

In the case of Vulkan though, there is no conflict of interest.

[Humbug]

 

How Does Vulkan Compare To OpenGL?

 

Vulkan allows applications to get closer to metal, thus eliminating the need for a lot of memory and error management, as well as a lot of shading language source. Drivers will be lighter, leaner and meaner. Vulkan will only rely on the SPIR-V intermediate language, and since it has a unified API for mobile, desktop and console markets, it should also get more tender, loving care from developers.

 

But wait, doesn’t this simply offload more work to game developers? Sure, they will be able to use hardware more efficiently, but what about their own man-hours? This is where the layered ecosystem approach enters the fray.

Developers will be able to choose three different levels, or tiers, of the Vulkan ecosystem.

• Use Vulkan directly for maximum flexibility and control.
• Use Vulkan libraries and layers to speed up development.
• Use Vulkan via off-the-shelf game engines fully optimised over the new API.

The first option clearly won’t be for everyone, but I suspect it would make for some nice benchmarking software. Khronos expects the second option to be a “rich area for innovation” because many utilities and layers will be in open source, and will ease transition from OpenGL. If a publisher has some OpenGL titles that need tweaking and updating, this is what they would use.

The last option is, perhaps, the most tempting one because the heavy lifting has been done by industry heavyweights such as Unity, Oxide, Blizzard, Epic, EA, Valve and others.

SPIR-V Is Expected To Transform The Language Ecosystem

GSLS will stay alive for now, and it will be the first shading language supported by Vulkan. A GLSL to SPIR-V translator will do the heavy lifting, and voila!, you’ll get SPIR-V ready to feed the hungry Vulkan runtime. Game developers will be able to use SPIR-V and Vulkan back-ends, probably relying on open-sourced compiler front-ends. In addition to GLSL, Vulkan can support OpenCL C kernels, while work on adding support for C++ is progressing. Future domain-specific languages, frameworks and tools are another option. Khronos even mentions the possibility of developing new experimental languages.

 

 

Whatever developers choose to do, all roads lead to Vulkan, via SPIR-V, and then to a multitude of different devices.

SPIR-V is supposed to improve portability in three ways:

• Shared tools
• Single tool set for a single ISV
• Simplicity

Since there will be no need for every hardware platform to feature a high-level language translator, developers will deal with less of them.

An individual ISV can generate SPIR-V using a single tool set, thus eliminating portability issues of the high-level language.

SPIR-V is simpler than a typical high-level language, making implementation and processing easier.

Performance will be improved in a number of ways, depending on how Vulkan is implemented:

• No more compiler front-end, a lot of processing can be done offline
• Optimisation passes can settle faster, optimisations executed offline
• Multiple source shaders reduce to the same intermediate language instruction stream

 

http://www.toptal.com/api-developers/a-brief-overview-of-vulkan-api

[Icecube26]

lets see how many games will support each API for now ..... DX 12 ( Fable Legend, Gears of War Ultimate PC, Deus Ex Mankind Divided, Ashes of Singularity, maybe SW Battlefront, Witcher 3 and Batman AK have dx 12 patch coming, a probably more to come) .... Vulkan ( 0 )... dont get me wrong... its a great API... but it will come out god knows when... by then DX 12 will be used by pretty much all the major devs... so i think... it might end up just like Mantle... its going to support few games here and there  ... but nothing major... but where it is going to shine are mobiles and tablets ... 

[Humbug]

but it will come out god knows when...

Within the next four months.

[Humbug]

 Vulkan ( 0 )..

It has confirmed support coming for Dota 2 and has already been shown. Plus all the big game engines are going to support both.

 

DX12 came out about 6 months before Vulkan so it has a head start. But the success of DX12 is only going to help Vulkan because of the similarities between the two. These handful of big devs getting familiar with the new paradigm of APIs via DX12 is actually good for Vulkan's future. They will definitely co-exist.