• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Khronos announces Vulkan (previously GLNext/Next-gen OpenGL)

Just curious...can this API be used for PS4?
I believe that used OpenGL, so just wondering if it is compatible with Vulcan?
PS4 doesn't use OpenGL, it uses libgcm. As far as I know it's also a command buffer API.

Sony could support Vulkan if they wanted to make life easier for developers, but it's completely up in the air whether this will happen.
 
Just curious...can this API be used for PS4?
I believe that used OpenGL, so just wondering if it is compatible with Vulcan?

They don't use OpenGL. PSGL was for ps3 but I heard it was never really used. Ps4 has its own low level api and I don't see any reason why they would change this.
 
Wow, nice catch. Here's the screenshot of valve's debugger:

Wx8eneE.png

Looks like a very similar workflow to Metal as well. Which I've enjoyed working with thus far.
 
ES3.1 support in the hardware will not mean all that much given that an OS update is still necessary as mobile devices don't allow you to "sideload" graphics drivers all that easily (e.g. rooting devices).

So for low- and mid-range mobile phones I don't think we'll see support there retroactively. Even on higher end devices it will likely depend on wether or not (and when) Google adds Vulkan support to Android in general. That Google will add it seems pretty much certain to me - they are the only ones not running their own API yet.

It's likely to get even more interesting with Apple's iOS. I am not aware of any statement from them stating support for it. I believe it's entirely possible that they'll stick with the combination of OpenGL and Metal for the forseeable future.

With Microsoft we can be pretty sure they won't support it on their closed platforms (Windows Phone, Xbox).

What will be interesting to see is what platforms they can show off in their presentation. I guess support on Steam OS is certain to be shown off. Given support by Qualcomm I'd also guess that we'll see a development device with Android. Regular Windows is the big question - seeing Vulkan running on the Win 10 Technical Preview would be huge. My guess would be to rather see Win7 or Win8 for now.
 
Just curious...can this API be used for PS4?
I believe that used OpenGL, so just wondering if it is compatible with Vulcan?

It's possible that Vulkan (and DX12 for that matter) could influence changes or improvements to PS4's libs. However, as always with a console, its its own variant for its own hardware specifically.

I think it's always kind of funny how people end up debating about consoles - particularly given that PS4's gnm/gcm has been credited with starting this whole trend for high level APIs with lower level control.
 
What will be interesting to see is what platforms they can show off in their presentation. I guess support on Steam OS is certain to be shown off. Given support by Qualcomm I'd also guess that we'll see a development device with Android. Regular Windows is the big question - seeing Vulkan running on the Win 10 Technical Preview would be huge. My guess would be to rather see Win7 or Win8 for now.
Imgtec already have a platform, driver and demo ready (credit to Turin Turambar for originally posting the link):
http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

Also, I don't think regular Windows is any issue. I expect NV, AMD and Intel to provide Vulkan drivers for all major versions of Windows (from 7 upwards).

I think this time it's called libgnm.
You're right.
 
I'm sure some dev could make a library for it but most likely this will be the standard API for PS5.

I don't see why this is likely. Sony spent a lot of work in the own api and still do. If this is able to translate to their next gpu, I don't know why they would drop it for Vulkan.
 
Just curious...can this API be used for PS4?
I believe that used OpenGL, so just wondering if it is compatible with Vulcan?

PS4's uses their own custom API GNM which already shares similar principles as Mantle and is somewhat just as good according to Johan Andersson.

That's not to say there can't be improvements though. Apparently you can bypass it.

foPgx1D.png
 
It's likely to get even more interesting with Apple's iOS. I am not aware of any statement from them stating support for it. I believe it's entirely possible that they'll stick with the combination of OpenGL and Metal for the forseeable future.

Why wouldn't Apple support it, when they are contributing to it?

Vulkan_6_575px.jpg
 
What? Unlike Mantle this is completely cross-vendor and cross-platform so no.

Vulkan works on practically everything. Huge difference

What?

Vulkan is an actual Khronos standard with wide industry support. It couldn't be more different from Mantle (in any aspect but the technical).

sure but it's not OpenGL 5. Well see how widely this will be adopted. Right now it's all talk, just like with mantle, "ground breaking" and all that handsome text. The fact they are separating Vulkan from the rest of openGL sounds ominous to me.
 
sure but it's not OpenGL 5. Well see how widely this will be adopted. Right now it's all talk, just like with mantle, "ground breaking" and all that handsome text.
We know that NV, AMD, Qualcomm and Imgtec are already working on drivers, and that both Unity and Epic are heavily involved. I'm really not sure where you're going with this.

The fact they are separating Vulkan from the rest of openGL sounds ominous to me.
Actually, that fact is why it's so exciting. OpenGL has 20 years of legacy baggage to carry around, as well as industry users who are notoriously resistant to change.
 
sure but it's not OpenGL 5. Well see how widely this will be adopted. Right now it's all talk, just like with mantle, "ground breaking" and all that handsome text. The fact they are separating Vulkan from the rest of openGL sounds ominous to me.
It sort of is OpenGL 5. It's just entirely redesigned and a bit pointless to keep the name OpenGL.
 
Why wouldn't Apple support it, when they are contributing to it?

I'm pretty sure MacOS will support it - iOS is the question - at least to me. MacOS will have to support it as lots of the design software companys (which is quite an important software branch on MacOS) are going to demand it.

But I guess we'll know more after the presentation.
 
PS4's uses their own custom API GNM which already shares similar principles as Mantle and is somewhat just as good according to Johan Andersson.

That's not to say there can't be improvements though. Apparently you can bypass it.

foPgx1D.png

Ah right, sorry to everyone quoting me, guess I was confused with PS3.

Interesting to see PS4 API has similar principles.
 
As much I think SPIR-V is paramount and the way forward, I think they'll face the exact same issue the original SPIR had in OCL: SPIR being based on llvm IR is both a blessing and a curse. It's a blessing because it is the arguably smartest IR out there (from the publicly available knowhow). It's a curse because there's no such thing as a standard llvm IR - it changes a few times per llvm revision, so from llvm's side it's a moving target. I think it'd be very nice if llvm thinktank sat dawn and devised a standard SSA, with versioning, BC and all. Otherwise we'll get yet another case of modern llvm not talking SPIR.
 
Actually, that fact is why it's so exciting. OpenGL has 20 years of legacy baggage to carry around, as well as industry users who are notoriously resistant to change.

wait, so this is a brand new API written from scratch?

edit: from ArsTechnica
SPIR provides a solution. Compilers can emit SPIR intermediate code, and drivers can process that directly. This avoids both the complexity of supporting the C-like language, and it gives developers much more flexibility: there are, among others, JavaScript, C++, Python, Java, and Haskell-based languages for writing these GPU compute programs, with the compilers producing SPIR code.
....
As well as SPIR-V, OpenCL 2.1 also includes support for writing GPU compute programs in a specialized subset of C++.
Holy shit, this is HUGE!
 
Vulkan (not Vulcan) in various languages means Volcano, which is likely a shout out to mantle or indication of its following
Vulcanos were named after the Roman god Vulcan, god of fire and metalworking. As was Vulcan, the planet once postulated to exist between Mercury and the Sun (the other planets are named after Roman gods, too).

The planet in Star Trek would have been named after the postulated planet. The link between the two names is pretty direct.
 
As much I think SPIR-V is paramount and the way forward, I think they'll face the exact same issue the original SPIR had in OCL: SPIR being based on llvm IR is both a blessing and a curse. It's a blessing because it is the arguably smartest IR out there (from the publicly available knowhow). It's a curse because there's no such thing as a standard llvm IR - it changes a few times per llvm revision, so from llvm's side it's a moving target. I think it'd be very nice if llvm thinktank sat dawn and devised a standard SSA, with versioning, BC and all. Otherwise we'll get yet another case of modern llvm not talking SPIR.
In case anyone else is like me and wasn't sure about these terms:

  • SPIR-V = Standards Portable Intermediate Representation (Vulkan?) = intermediate representation discussed earlier
  • SPIR = Standards Portable Intermediate Representation = same thing but older version
  • LLVM = apparently not an acronym, but the name of a compiler / toolchain project
  • LLVM IR = Intermediate Representation used by the LLVM project
  • SSA = Static Single Assignment (form?) = possibly a simple and clear form that an Intermediate Representation can take? I'm not certain on this one.
  • BC = Backwards Compatibility, so syntax can be updated like shader language syntax, and different versions of the syntax could be supported
 
I wonder if we could actually see "real" "AAA" Windows games written with Vulkan rather than DirectX. That woud be fantastic, and it seems like it could make a lot of sense. Most likely very similar performance and feature sets, but you can reach everyone rather than just those on Windows 10.

Well, we have seen "real" "AAA" Windows games using OpenGL (Rage, Wolf: TNO, etc), so I don't see why not.
 
Well, we have seen "real" "AAA" Windows games using OpenGL (Rage, Wolf: TNO, etc), so I don't see why not.
Both of those games are running on the id Tech 5 engine which is the exception rather than the rule.

However, Valve has presumably been working on supporting OpenGL with Source 2, and there seems to be some experimental OpenGL support in Unreal Engine 4.

LLVM = Low Level Virtual Machine

I don't think the full name is used any more however.
Yes, that was apparently the old name. The website now says:

The name "LLVM" itself is not an acronym; it is the full name of the project.

Which sounds a little snobbish but eh. :P
 
As much I think SPIR-V is paramount and the way forward, I think they'll face the exact same issue the original SPIR had in OCL: SPIR being based on llvm IR is both a blessing and a curse. It's a blessing because it is the arguably smartest IR out there (from the publicly available knowhow). It's a curse because there's no such thing as a standard llvm IR - it changes a few times per llvm revision, so from llvm's side it's a moving target. I think it'd be very nice if llvm thinktank sat dawn and devised a standard SSA, with versioning, BC and all. Otherwise we'll get yet another case of modern llvm not talking SPIR.
I agree with everything you just said (except, of course, that the llvm IR is only the smartest low-level IR, since obviously the smartest high-level IR is INSPIRE ;)).

It would be quite a hindrance for future tool development not to be able to use the latest version of llvm.
 
PowerVR Demo of Vulkan.


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

Introducing one of the first demos using the Vulkan API

Imagination is a promoting member of the Khronos Group and has been working on developing a proof-of-concept driver for Vulkan for our PowerVR Rogue GPUs. Our PowerVR demo team has also spent the last two months porting one of our new OpenGL ES 3.0 demos to the new API and today we are able to show you a snapshot of our work.

The Library demo was originally created using the OpenGL ES 3.0 API and we worked on porting it to the Vulkan API at the same time as the API was being designed. We needed to remove some of the effects compared to the OpenGL ES 3.0 version because of time constraints but the demo still maintains a lot of features implemented in the original app. Here is a summary of what you can see in the video below:

  • High-quality, physically-based shading
  • HDR (High dynamic range) rendering
  • 20 unique 2K PVRTC textures
  • 2 GiB of texture data compressed to 266 MiB using Imagination’s PVRTC texture compression standard
  • 4 x MSAA (Multi-sample anti-aliasing)
  • 16 x Anisotropic texture filtering
  • Physically-correct material parameters
  • Low CPU usage, very efficient GPU usage
  • Correct specular reflections on reflective materials
  • More than 250,000 triangles
  • Post processing effects: saturation, exposure and tone mapping

Cpu Usage comparison:
oglesvsxgl.png

(left is Vulkan, right OpenGL ES 3.0)

In Vulkan, 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. Whilst this 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.

Much more at the link
 
It is my hope that a few years from now we will all look back upon this as the day PC gaming finally broke free of Microsoft's grip. Yes, there is a lot of work to be done, but this time I believe that all the necessary pieces are in place to bring about an actual revolution in the industry.
 
Nahh not really.

DirectX 12 will still be widely used.
Especially when its being used on both PC and Xbox One. It makes the dev's job a lot easier.

And of course it is not only API. How is it supported in IDEs? What debugging tools are available, how good are they? How portable is the code? How fast is it available? How is it supported by the "vendor"?
 
Only if DX12 doesn't offer an equivalent feature set. If it does, nothing will change.
I'm not 100% convinced of that. If the clean slate, standardized IR and improved conformance testing of Vulkan combined manage to solve most of OpenGL's glaring problems then I don't see why it wouldn't become more widely used on (Windows) PC as well.
 
Top Bottom