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:
After Vulkan:
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.
They even include some fancy pictures for the simple folk.
Before Vulkan:
After Vulkan:
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.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
9 comments
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).
0 Likes
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.
Afaik one of the main points of Mantle was to reduce CPU overhead.
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).
Afaik one of the main points of Mantle was to reduce CPU overhead.
1 Likes, Who?
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).
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.
1 Likes, Who?
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).
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)
0 Likes
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).
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
1 Likes, Who?
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?
0 Likes
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).
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.
1 Likes, Who?
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
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
0 Likes
The 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
0 Likes
Patreon
PayPal
See more from me