Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Another AMD blog post on Vulkan, this time with info about multithreading

By - | Views: 12,314
While AMD may not have a Linux driver ready for Vulkan, they are still getting me excited about it with their blog posts.

They even include some fancy pictures for the simple folk.

Before Vulkan:
image

After Vulkan:
image

QuoteBaking is an interesting concept but could easily transform into bottlenecks if the process is limited to a specific thread. Fortunately, with Vulkan, applications are no longer limited to single-threaded rendering contexts, which often forced them to perform expensive inter-thread synchronization. With the new API, your application can freely issue API calls from any thread it wants, as long as it follows object access synchronization requirements. In other words, as clearly stated in the Vulkan specification, the more threads the CPU can run simultaneously, the quicker the GPU can start drawing frames – as long as Vulkan applications distribute the baking process across all available CPU cores.

Multi-thread support in the API is just one side of the coin. Vulkan introduces analogous concept on the GPU side. With AMD’s GCN architecture and the new API, developers gain direct access to distribution of GPU work to separate command queues. This means that you can have one queue working on physics calculations, while the other one works on rasterization. Keeping the GPU busy at all times helps avoid the pipeline bubbles I mention earlier – this is crucial for achieving the best rendering performance possible.


For CPU-bound games, Vulkan could offer a decent performance boost, but like everything it has to be done correctly and requires extra time from developers to learn the ins and outs of this brand new API. Don't expect a quick turnover for this.

See the full blog post on it here. It also has some more info about SPIR-V and renderpasses. Article taken from GamingOnLinux.com.
Tags: AMD, Editorial, Vulkan
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
9 comments

mao_dze_dun Feb 18, 2016
Somebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound. As in the card is artificially bottlenecked on a single core instead of using them all. If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).
lvlark Feb 18, 2016
All of this 'Vulkan can give more performance, if devs put in more time' is probably good for pre-built engines like Unity, Frostbite, Unreal, etc. because they have the resources to really optimise things, whereas smaller teams can't. Hence, OpenGL will continue to be relevant if you don't want to use someone else's engine for some reason.

Quoting: maodzedunSomebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound. As in the card is artificially bottlenecked on a single core instead of using them all. If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).

Afaik one of the main points of Mantle was to reduce CPU overhead.
amonobeax Feb 18, 2016
Quoting: maodzedunSomebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound. As in the card is artificially bottlenecked on a single core instead of using them all. If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).

Yeah, most DX11 games relied on strong optimization on the first CPU core.

That was one of the reasons AMD's CPUs would perform so much worse than Intel's. AMD always focused more on expanding the number of cores than in optimizing a single core to be faster.

Since the new trend is Async Computing (instead of multi threading). This can flip the table.


Bottom line: Vulkan is can be a life changer to AMD both in CPU and GPU.
mao_dze_dun Feb 18, 2016
Quoting: amonobeax
Quoting: maodzedunSomebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound. As in the card is artificially bottlenecked on a single core instead of using them all. If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).

Yeah, most DX11 games relied on strong optimization on the first CPU core.

That was one of the reasons AMD's CPUs would perform so much worse than Intel's. AMD always focused more on expanding the number of cores than in optimizing a single core to be faster.

Since the new trend is Async Computing (instead of multi threading). This can flip the table.


Bottom line: Vulkan is can be a life changer to AMD both in CPU and GPU.

I was referring to the Linux performance mostly. AMD is pretty decent on Windows. On Linux there is this weird invisible ceiling hit by anything in the range between 370 and a Fury X, which I thought was a result of the driver bottlenecking its own card by not utilizing multi-threading (I bet I sound like a caveman trying to talk about astronomy :D)
mrdeathjr Feb 18, 2016
Quoting: maodzedunSomebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound.

As in the card is artificially bottlenecked on a single core instead of using them all.

If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).

This is because amd dont have powerfull cpu, your actual design have higher latencies compared with intel: for example L2 on actual amd cpu is more slow than L3 on intel (L3 is more slow than L2)

Shared FPU, many app use strong fpu and amd lacks of them

Lower Instructions Per Cycle compared with intel cpus and gap is more bigger when have intel cpu at 4.0Ghz or more

However with appears zen, various issues can be fixed (FPU, SMT and maybe others), for now zen have use SMT (this must be fix various issues) and have one FPU for each ALU as is used in regular intel cpus

Vulkan improve multitasking, however in amd this dont bright completly until appears zen in someplace around begins 2017 for now

For now stay waiting for zen, hopefully improve some if only stay in middle ivy bridge and more closer of haswell in performance / core must be good cpu

^_^


Last edited by mrdeathjr on 19 February 2016 at 1:17 am UTC
Purple Library Guy Feb 18, 2016
Does anyone else find it a weird contrast that AMD are busy putting out all these no doubt highly useful resources about how to do stuff with Vulkan, but can't seem to put out a driver that does stuff with Vulkan?
jamesc359 Feb 18, 2016
Quoting: maodzedunSomebody more knowledgeable than me, correct me, but I thought a large part of the AMD performance problems on Linux were CPU bound. As in the card is artificially bottlenecked on a single core instead of using them all. If that is the case Vulkan can finally solve that problem (for Vulkan games obviously).

Basically yes, but there's more to the issue than just OpenGL's/DX11's use of a single threaded command queue. The other major issue is the excessive amount of error checking both APIs do on data passed to them from the game. That error checking was obviously a good thing back in the day when our video cards were relatively weak and could only render a small number of objects. Times have changed though and now our cards can handle rendering an increasingly larger numbers of objects and the CPU just can't keep up with all that overhead.

So with Vulkan and DX12, even if you limited yourself to using a single thread to interact with the API you'd still see some significant performance gains. The multi-threaded command queue is the icing on top of the cake here.

It's also worth noting that this problem afflicts NVidia on Linux and Windows as well. The problem is however less pronounced on Windows - in particular with DX11 - since NVidia and AMD have done a lot of work on optimizing their drivers and hardware specifically for DX.
Shmerl Feb 18, 2016
Quoting: lvlarkAll of this 'Vulkan can give more performance, if devs put in more time' is probably good for pre-built engines like Unity, Frostbite, Unreal, etc. because they have the resources to really optimise things, whereas smaller teams can't

Why can't smaller teams do it? If performance is critical for their success, they'll focus on it first. It's not about the size of the team, but about knowledge and ability to learn. Just throwing more people at the problem doesn't necessarily solve it better.


Last edited by Shmerl on 18 February 2016 at 11:00 pm UTC
Shmerl Feb 18, 2016
Quoting: jamesc359The multi-threaded command queue is the icing on top of the cake here.

Not just that. With Vulkan you can even use multiple queues simultaneously as long as the GPU supports many of them. Including compute queues. So it's not just several threads per queues, but several queues at the same time as well which allows saturating the GPU to its full potential.


Last edited by Shmerl on 18 February 2016 at 11:03 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.