Jobs Store Support Register
FAN ART (THE WITCHER UNIVERSE)
FAN ART (CYBERPUNK UNIVERSE)
OTHER GAMES
BRAZILIAN COMMUNITY
ITALIAN COMMUNITY
JAPANESE COMMUNITY

Vulkan - new generation cross platform graphics and GPGPU computing API

+
D

Doctalen

Rookie
#21
Source 2 has Vulkan support. Not sure if this is news, I'm just hearing about Vulkan.

https://steamdb.info/blog/source2-announcement/

"There will also be Vulkan support in Source 2, we'll probably hear more about Vulkan (and Valve's involvement) in the upcoming GDC talk."

"Also as part of supporting PC gaming, Valve announced that it will be releasing a Vulkan-compatible version of the Source 2 engine. Vulkan is a cross-platform, cross-vendor 3D graphics API that allows game developers to get the most out of the latest graphics hardware, and ensures hardware developers that there is a consistent, low overhead method of taking advantage of products. Vulkan, previously called Next Generation OpenGL, is administered by the Khronos Group, along with other standards such as OpenCL, OpenGL, and WebGL."
 
Last edited:
Gilrond-i-Virdan

Gilrond-i-Virdan

Mentor
#23
A very good article about SPIR-V: http://www.g-truc.net/post-0714.html

sidspyker said:
It's news but expected since Valve has been on the Vulkan team since forever
Click to expand...

I'd even guess that Valve were the primary driver behind the whole OpenGL overhaul which resulted in Vulkan. Without them Khronos probably would have done nothing of this sort. So support for it in their engines is natural to expect.

---------- Updated at 04:50 AM ----------

sidspyker said:
On a semi-related note, in a move surprising no one(if anything it was expected) Mantle SDK has been cancelled, the spec/code won't be open-sourced like they planned earlier.
Click to expand...

Yeah, AMD clarified the relation between Mantle and Vulkan: http://community.amd.com/community/...blog/2015/03/03/one-of-mantles-futures-vulkan

The cross-vendor Khronos Group has chosen the best and brightest parts of Mantle to serve as the foundation for “Vulkan,” the exciting next version of the storied OpenGL API.

OpenGL has long and deservedly commanded respect for being a fast, versatile and wide open API that works on all graphics vendors across multiple operating systems.

Meanwhile, Mantle has seen acclaim for many improvements in gaming and game development: higher framerates, reduced rendering latency, reduced GPU power consumption, better use of multi-core CPUs, and re-pioneering new features like split-frame rendering.

Vulkan combines and extensively iterates on these characteristics as one new and uniquely powerful graphics API. And as the product of an incredible collaboration between many industry hardware and software vendors, Vulkan paves the way for a renaissance in cross-platform and cross-vendor PC games with exceptional performance, image quality and features.
Click to expand...

That's pretty much what was expected.

---------- Updated at 05:39 AM ----------

@Guy N'wah : reading around, I found that all these new APIs use the same idea of command queue. There is some need to order command buffers when submitting them to the GPU.

Examples:

* Metal
* DX12
* Mantle

Mantle page explicitly mentions that there can be multiple queues per GPU. Others are ambiguous about it, but I assume they can have multiple too. From the Mantle page it appears that different queues are used for different types of tasks.

My guess is, that when ordering is needed logically - commands should end up in one queue so they'd be executed sequentially. When something is independent, then they can end up on different queues so they'd be executed completely in parallel.

As such, I think such logic can apply to any of these APIs and probably to Vulkan as well. And that initial diagram just shows example of one such queue.
 
Last edited:
G

GuyNwah

Ex-moderator
#29
@Gilrond
An analogous situation exists in the NIC realm, which is closer to my own work. High-performance NICs do have multiple queues and do not require work to be submitted from a single thread. (On HT processors, it's a common restriction that the threads interacting with the NIC be on physical cores, but multiple threads are submitting work and waiting for interrupts from a single NIC.)

This is why I was surprised to see a representation of what is or should have been canonical Vulkan application architecture featuring a single thread for all interaction with the GPU. If it was just an example, I think it raises more questions than it answers.
 
Gilrond-i-Virdan

Gilrond-i-Virdan

Mentor
#30
@Guy N'wah : By the way, are you sure that all GPUs can execute commands in parallel? And can those be the same type of commands? From the Mantle diagram it looks like they separate them by graphics, compute, etc. Is there anything AMD specific in it? Since Vulkan is supposed to be generic, may be it can't rely on the same assumption that Mantle did, and has to account for different types of GPUs, including mobile ones.

---------- Updated at 06:51 PM ----------

An important bit from the Vulkan presentation:

Unlike previous GLs, Khronos will offer a Vulkan SDK
Click to expand...

Hopefully it will simplify all this OpenGL implementations mess.
 
G

GuyNwah

Ex-moderator
#31
GCN devices have two DMA channels, and they're not being used at peak efficiency if you have only one thread commanding them.

Fermi and later devices can have as many CPU-side threads controlling CUDA kernels as the kernel count supported by the device.

Userland concurrency is even more important on small power-constrained platforms. The big win in power consumption is to have all 4 or 8 bogocores running at a lower frequency and voltage than a single dispatching thread can achieve.

This is why my concern abides that we are seeing a model that has not advanced beyond DirectX 11 or nVidia bindless OpenGL. I would very much like for my concern to be misplaced. But I have done this too long to trust anything not in evidence.
 
G

GuyNwah

Ex-moderator
#33
@Gilrond : Parallel as all hell. Volsung could explain this better, and AMD and nVidia terminology differ ("warp" in nVidia, "wavefront" in AMD, "work unit" in OpenCL), but a single GPU is broken into a (potentially large) number of SIMT units. (A full-on 2880-shader Kepler can be running 180 work units, or 60 if they are doing double precision arithmetic.)

Decomposition into different stages of the graphics pipeline and separate compute tasks makes the kernel run by each SIMT unit smaller, and small short programs are a big win. But these stages are all proceeding simultaneously, for consecutive frames.
 
Gilrond-i-Virdan

Gilrond-i-Virdan

Mentor
#34
@Guy N'wah : What about Qualcomm Adreno for example?

It makes sense that there should be an option to use multiple command queues if hardware itself supports simultaneous execution in some way. The question is whether it's consistent across all GPUs or very hardware specific. May be API can give an option to use one or more queues, and developers would decide how to apply that depending on the GPU. But that makes the code more clunky and kind of defeats the purpose of making it easily portable.
 
Last edited:
G

GuyNwah

Ex-moderator
#35
Gilrond said:
@Guy N'wah : What about Qualcomm Adreno for example?

It makes sense that there should be an option to use multiple command queues if hardware itself supports simultaneous execution in some way. The question is whether it's consistent across all GPUs or very hardware specific. May be API can give an option to use one more more queues, and developers would decide how to apply that depending on the GPU. But that makes code more clunky and kind of defeats the purpose of making it easily portable.
Click to expand...

Qualcomm's Snapdragon (Adreno GPU) is heavily multithreaded. Some games have implemented a run on multiple threads option, with varying degrees of success.

You're right, it's easier to program to a lowest common denominator, but the single-threaded GPU interface has been out of fashion since Fermi, and the biggest wins in graphics performance have been in middleware that doesn't fall back to it.
 
G

GuyNwah

Ex-moderator
#37
Gilrond said:

---------- Updated at 06:07 AM ----------

@Guy N'wah : They mention multiple command queues support in the API.
See at https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s

I think it addresses your question. It's like I guessed above. API will let you query how many queues the hardware supports (and what types), and then it's up to you how to use them.
Click to expand...

That is the manner of reassurance that I wanted to hear. The proof of such a complex pudding remains in the eating, but yes, that does indicate you do not have to use a single thread as a dispatcher.
 
Gilrond-i-Virdan

Gilrond-i-Virdan

Mentor
#38
About C++ vs C (they answered it in Q&A section, but without any strong arguments). While I'd usually say why not C++, in this case C is actually providing a clear benefit. Binding from other languages is so much easier to C because C ABI is rather straightforward (unlike C++ ABI).

For example consider making bindings to Vulkan from Rust (I'm sure Rust developers will want to do that as soon as Vulkan will come out, since it's such an important key library). If it would have been in C++, bindings would be hugely more complex to implement than with C. So in this case the fact that Vulkan uses C will save a lot of time for language developers.
 
Last edited:
Top Bottom