Nvidia's Performance Under Vulkan API Explored

[Hitman928]

Just sharing what I found in benching with presentmon on Vulkan. First video is about Doom but will have a follow-up video shortly. Also doing more investigating into whether some of what I'm seeing is due to the tool or not. I'm not a video editor or a youtube personality by any means, this is just something I wanted to try so be nice

Video

Results start at 2:30

*UPDATE*

DOTA 2 results in second video.

Video 2

 

[ViRGE]

Wouldn't it be better to say that it's NVIDIA's performance under Doom's Vulkan render, rather than generic Vulkan performance? Granted, Doom is the only real Vulkan game out there, but it's a bit like saying the early builds of Tomb Raider were representative of all DX12 games.

 

[Hitman928]

Video is specific to doom, but I have more tests I'm working on putting together and wanted to keep it to 1 thread, so thread title is more general.

 

[TheRyuu]

From guru3d forums[1]:

Stuttering is due to a bug in flip queue handling which is either on id's or NV's side (I think it may have something to do with id using present from compute queue to reduce latency which isn't supported by NV h/w right now - or possibly ever - illustrating again that Doom's VK renderer is a 100% GCN/AMD effort which doesn't contain any specific optimizations for NV h/w). This stuttering is heavily affecting average fps results btw as cards like GTX1080 is loosing some 30% of performance because of this.

Id is still yet to provide support for Pascal's async compute and NV's shader intrinsics of which the latter seems to be responsible for the lion's share of performance gains on GCN. As of right now Doom's VK can be considered a port of id's console code back to PC, under VK AMD extensions. As such it does not provide a proper comparative picture to what NV h/w can achieve in the same API, especially if you consider that in TPP (the only other VK game we have right now) the picture is exactly opposite with NV winning and AMD loosing:

I can't speak to how accurate this information is but it's one suggested theory as to why we're seeing this behavior under Vulkan in Doom.

[1] http://forums.guru3d.com/showthread.php?s=63f1637357edccf50957eae04380948a&p=5318782#post5318782

 

[littleg]

That's interesting. As far as I know ID have been working with both NV and AMD on this so i'm surprised those NV optimisations haven't been incorporated.

 

[misuspita]

I would call BS on that post on guru forums. Nvidia worked close with iD, in fact used Doom to showcase 1080 launch. So yeah, BS

 

[Carfax83]

I would call BS on that post on guru forums. Nvidia worked close with iD, in fact used Doom to showcase 1080 launch. So yeah, BS

So just because ID showcased Doom on NVidia hardware, it means that their Vulkan renderer was completely optimized for NVidia?

That's hardly a water tight correlation. NVidia's Vulkan driver isn't as advanced as AMD's is for starters, due to NVidia focusing mostly on DX12, and Vulkan utilizing a significant amount of the Mantle codebase... Secondly, ID has also incorporated GCN shader intrinsic functions as extensions for their Vulkan renderer, something they already used with the console versions for the ultimate low level access.. Thirdly, asynchronous compute isn't even supported yet for Pascal in their Vulkan renderer, while it is for GCN.

So it's not a question of whether ID is buddy buddy with NVidia over AMD or vice versa. It's a question of the level of optimization that has been accomplished so far for either vendor.

And from that standpoint, it's obvious that AMD has received a lot more low level optimization than NVidia has, mostly for practical reasons, as stated above.

 

[Bacon1]

So just because ID showcased Doom on NVidia hardware, it means that their Vulkan renderer was completely optimized for NVidia?

That's hardly a water tight correlation. NVidia's Vulkan driver isn't as advanced as AMD's is for starters, due to NVidia focusing mostly on DX12, and Vulkan utilizing a significant amount of the Mantle codebase... Secondly, ID has also incorporated GCN shader intrinsic functions as extensions for their Vulkan renderer, something they already used with the console versions for the ultimate low level access.. Thirdly, asynchronous compute isn't even supported yet for Pascal in their Vulkan renderer, while it is for GCN.

So it's not a question of whether ID is buddy buddy with NVidia over AMD or vice versa. It's a question of the level of optimization that has been accomplished so far for either vendor.

And from that standpoint, it's obvious that AMD has received a lot more low level optimization than NVidia has, mostly for practical reasons, as stated above.

So what you are saying is, AMD's driver team is able to produce better vulkan drivers than Nvidia's? Here I thought that Nvidia had the best driver team out there and AMD's was trash. Thats what I keep hearing on these forums anyway.

Lets ignore that many core members of Khronos work at Nvidia, as well as it being almost a full month since the Vulkan patch and still no updated drivers for Nvidia. Sounds familiar to those waiting for Maxwell Async Compute drivers for Ashes of the Singularity. Been a full year waiting for those already.

Lets also ignore id specifically saying that were working close with both AMD and Nvidia daily on the vulkan release, and Nvidia having id up on stage to show off the 1080 running Doom in Vulkan (first showing of vulkan out there).

Since late March 2016 we started working daily with both AMD and NVIDIA. Both have been great partner companies, helping bring full DOOM and Vulkan driver support live to the community. There was a lot of work on all fronts but we are pleased with the results.

https://bethesda.net/#en/events/game/doom-vulkan-support-now-live/2016/07/11/156

http://www.pcgamer.com/id-software-shows-doom-running-on-gtx-1080-using-vulkan/

 

[littleg]

If the software isn't written to take advantage of those features, though, there's not much a driver can do to help. If they've been working as closely with NV as they say then the question has to be why didn't NV help them with this and expose those features? Alternatively they've overstated their relationship with NV on this title and have primarily optimised for AMD, in which case I would at the very least expect a patch to get these same beneficial features working on NV hardware.

 

[Carfax83]

So what you are saying is, AMD's driver team is able to produce better vulkan drivers than Nvidia's? Here I thought that Nvidia had the best driver team out there and AMD's was trash. Thats what I keep hearing on these forums anyway.

This is basically irrelevant to what we are discussing.

Lets ignore that many core members of Khronos work at Nvidia, as well as it being almost a full month since the Vulkan patch and still no updated drivers for Nvidia. Sounds familiar to those waiting for Maxwell Async Compute drivers for Ashes of the Singularity. Been a full year waiting for those already.

Lets also ignore id specifically saying that were working close with both AMD and Nvidia daily on the vulkan release, and Nvidia having id up on stage to show off the 1080 running Doom in Vulkan (first showing of vulkan out there).

What you heard on these forums, or what ID said about working close with AMD and NVidia and blah blah blah is nullified by the fact that Vulkan currently:

1) Shares a significant amount of it's codebase with Mantle, a GCN specific low level API.

2) Supports GCN shader intrinsic functions via extensions, which are basically low level console optimizations; lower than even what Vulkan provides.

3) Supports asynchronous compute on GCN, but not on Pascal.

I've played through Doom twice, and even after Vulkan became available, I didn't use it as it's terrible compared to OpenGL 4.5 for NVidia users. On my GTX 980 Ti I had microstuttering using the Vulkan path, and after I bought my GTX 1080 I experienced the same problem; especially in the Argent Tower, which is the most CPU limited area in the game.

So as far as I'm concerned, Vulkan is BROKEN on NVidia hardware at the moment.

 

[Leadbox]

This is basically irrelevant to what we are discussing.



What you heard on these forums, or what ID said about working close with AMD and NVidia and blah blah blah is nullified by the fact that Vulkan currently:

1) Shares a significant amount of it's codebase with Mantle, a GCN specific low level API.

2) Supports GCN shader intrinsic functions via extensions, which are basically low level console optimizations; lower than even what Vulkan provides.

3) Supports asynchronous compute on GCN, but not on Pascal.

I've played through Doom twice, and even after Vulkan became available, I didn't use it as it's terrible compared to OpenGL 4.5 for NVidia users. On my GTX 980 Ti I had microstuttering using the Vulkan path, and after I bought my GTX 1080 I experienced the same problem; especially in the Argent Tower, which is the most CPU limited area in the game.

So as far as I'm concerned, Vulkan is BROKEN on NVidia hardware at the moment.

Everything is waiting on that elusive async compute driver from nvidia, and all your stutters will be gone. I have a feeling the context switching and faster preemption is the source of all your stutters, stopping and switching is bound to cause delays. Performance for nvidia hardware right now CANNOT get any better than what you get with DX11 or OGL, we have here serial API optimized deep pipeline architectures that fail to gain performance from multi engine APIs.

 

[Cookie Monster]

Carfax83 has a point though. Doom was released multi platform e.g PS4 and XB1 so whatever Vulkan implementation they had for their desktop counterparts would have worked flawlessly or close to it due to the amount of time spent. However with nVIDIA i doubt the same amount of time has been spent in regards to Vulkan. OpenGL4.5 however works flawlessly on nVIDIA hardware which they must be prioritized first for their PC release of the game.

So Im willing to bet that we will see some of an update in the future from id to boost performance on nVIDIA hardware using Vulkan. Its not all about the async either (it does get a little tiresome when every user and their dog thinks DX12 = async compute). There are other things far more than async compute that could potentially provide increased performance. What works for AMD might well be different to nVIDIA because their architectures differ tremendously (i'd say this is the beauty of GPU architectures and its ongoing battles to crunch graphics works faster).

Also as a side note I suffer from some sort of a keyboard input lag (even if I observe alot higher FPS vs OpenGL4.5) so something is definitely up with the Vulkan implementation with NV hardware.

 

[eddman]

Everything is waiting on that elusive async compute driver from nvidia, and all your stutters will be gone.

Async on Pascal is already enabled; Time Spy.

we have here serial API optimized deep pipeline architectures that fail to gain performance from multi engine APIs.

Since when GPUs became serial?!! A GPU, by its nature, can NOT be serial.

 

[Leadbox]

Async on Pascal is already enabled; Time Spy.

So it's enabled on a per app/game basis? Don't you find it odd they have it seemingly working for a canned benchmark but not for actual games?

Since when GPUs became serial?!! A GPU, by its nature, can NOT be serial

.
I said the gpu was optimised for serial APIs' not that they were serial themselves, with my main point being they cannot take advantage of multi-engine processing like AMD gpus do.

 

[eddman]

So it's enabled on a per app/game basis? Don't you find it odd they have it seemingly working for a canned benchmark but not for actual games?

Of course it is. Isn't that obvious? It's up to the developer to code for async and take advantage of it, same as AMD's async. Based on what Ryan wrote last time, among DX12 games, only RotTR utilizes Pascal's async. I don't know if that has changed since.

Just because time spy gains frames on Pascal, doesn't mean it's "canned".

 

[Leadbox]

Of course it is. Isn't that obvious? It's up to the developer to code for async and take advantage of it, same as AMD's async. Based on what Ryan wrote last time, among DX12 games, only RotTR utilizes Pascal's async. I don't know if that has changed since.

Just because time spy gains frames on Pascal, doesn't mean it's "canned".

So Oxide and iD waiting on the asyc driver from nvidia is a lie, they just need to code for it on nvidia hardware? Ok.
*synthetic benchmark is what I should have wrote, which makes it even worse than a canned benchmark.

 

[MaxDepth]

We still have to remember that Vulkan was just released five months ago, so we cannot even say that the platform is mature, although in many cases more advanced than previous video APIs at their v1.0 level. Also, Vulkan comes from Mantle, an AMD product. While that speaks to advancement of Vulkan 1.0, it does show that it relied mostly on AMD know-how. And by know-how, I mean how AMD designed Mantle to read AMD and only AMD computing attributes.

So while the Vulkan (actually the Khronos Group) strives for being platform agnostic, nVidia and Vulkan still have a steeper path to excellence in GPU computational and rendering output. I know there is no sabotage or intended hobbling of one competitor over another.

So my question is, can nVidia utilize the current version of Vulkan's generic processes while finding a way to have the Vulkan API leverage the nVidia specific computing attributes? I don't see it happening in 2016 but I don't see that as being impossible in 2017. Like I said, nVidia is basically starting from scratch to come to Vulkan, so that is taking more time and effort than it does from AMD. So, does nVidia spend more resources on Vulkan so that it competes equally or better than AMD or does it spend more time going application to application (mostly games) and build more specific driver updates?

 

[Bacon1]

This is basically irrelevant to what we are discussing.

No it isn't, drivers still have to support Async Compute and Nvidia isn't providing working drivers. It's a "Fun Fact" that they still don't support Maxwell even though they sold them as supporting it.

http://www.geforce.com/whats-new/articles/geforce-gtx-is-game-ready-for-windows-10-and-directx-12

https://twitter.com/PellyNV/status/702556025816125440

What you heard on these forums, or what ID said about working close with AMD and NVidia and blah blah blah is nullified by the fact that Vulkan currently:

1) Shares a significant amount of it's codebase with Mantle, a GCN specific low level API.

So? So does DX12 according to id.

http://www.dsogaming.com/interviews...n-mega-textures-pbr-global-illumination-more/

2) Supports GCN shader intrinsic functions via extensions, which are basically low level console optimizations; lower than even what Vulkan provides.

So Nvidia needs to up their low level support to match AMDs?

3) Supports asynchronous compute on GCN, but not on Pascal.

And once again, waiting on async compute drivers from Nvidia. Wonder if it will be another "Fun Fact" that its still missing a month later.

I've played through Doom twice, and even after Vulkan became available, I didn't use it as it's terrible compared to OpenGL 4.5 for NVidia users. On my GTX 980 Ti I had microstuttering using the Vulkan path, and after I bought my GTX 1080 I experienced the same problem; especially in the Argent Tower, which is the most CPU limited area in the game.

So as far as I'm concerned, Vulkan is BROKEN on NVidia hardware at the moment.

Well considering they've worked directly with Nvidia for months, and Nvidia had them on stage to show off how well Vulkan ran trying to say they only spent time optimizing for AMD is absurd.

Since late March 2016 we started working daily with both AMD and NVIDIA. Both have been great partner companies, helping bring full DOOM and Vulkan driver support live to the community. There was a lot of work on all fronts but we are pleased with the results.

https://bethesda.net/#en/events/game/doom-vulkan-support-now-live/2016/07/11/156

 

[Headfoot]

It's incredibly obvious nVidia and ID demoing Doom pre-release on a 1080 is important. Attempts to downplay this are ridiculous.

That's an endorsement in every sense of the word, the marketed together, they put together an event to show Doom on Nvidia hardware. That means, at the very least 1) nVidia had pre-release access to Doom's Vulkan path, 2) they in fact got Pascal working on Doom's Vulkan path, 3) they felt confident enough in that Vulkan path to publicly demonstrate their card on it.

It's not a difficult conclusion to arrive at. A little deduction is all thats required

 

[Hitman928]

I have a feeling the context switching and faster preemption is the source of all your stutters, stopping and switching is bound to cause delays. Performance for nvidia hardware right now CANNOT get any better than what you get with DX11 or OGL, we have here serial API optimized deep pipeline architectures that fail to gain performance from multi engine APIs.

It has nothing to do with that, watch the video, it's a synch issue between Nvidia cards and the monitor under Vulkan. I have a theory as to what is going on, but doing more testing.

Also as a side note I suffer from some sort of a keyboard input lag (even if I observe alot higher FPS vs OpenGL4.5) so something is definitely up with the Vulkan implementation with NV hardware.

Watch the video and you'll see why you feel that input lag.

Second video with Dota 2 results uploaded here

 

[eddman]

So Oxide and iD waiting on the asyc driver from nvidia is a lie, they just need to code for it on nvidia hardware? Ok.
*synthetic benchmark is what I should have wrote, which makes it even worse than a canned benchmark.

Have you been following the latest Pascal developments at all? Did you read anandtech's 1080/1070 review? Async is only enabled in drivers for Pascal and it'll probably never be enabled for Maxwell, since it might actually end up hurting it, per Ryan's Pascal review.

Oxide was talking about Maxwell, and they weren't lying. Have they made a new comment about Pascal?

Even when it is enabled in the driver, it's up to the developer to utilize async in the game's code. It doesn't just magically work by itself.

Are you saying 3dmark is cheating in their tests?

So Nvidia needs to up their low level support to match AMDs?

And once again, waiting on async compute drivers from Nvidia. Wonder if it will be another "Fun Fact" that its still missing a month later.

Well considering they've worked directly with Nvidia for months, and Nvidia had them on stage to show off how well Vulkan ran trying to say they only spent time optimizing for AMD is absurd

... or developers should optimize their code for Pascal? We don't really know what's going on, yet.

Async for Pascal is enabled in drivers.

Yes, they worked with NVidia, but maybe that was to simply make the game work through vulkan on NVidia cards, and not a full-blown performance optimization? Again, we don't really know.
It might as well be that Pascal is inherently slower than GCN in low-level APIs, no matter what NVidia and game developers do, and will be slower in pretty much all DX12/vulkan games going forward, but it'd be better to wait a bit longer before coming to a conclusion. A handful of games don't paint a clear picture.

--------------------

As for the subject matter, we don't really know what's going on with Doom and Pascal. Yes, id demoed vulkan on NVidia cards in the past, but that doesn't necessarily mean that it is fully performance optimized for Pascal.

The vulkan results on Pascal are a bit odd to say the least. I think we'd have to wait for more vulkan games to show up.

 

[Hitman928]

The vulkan results on Pascal are a bit odd to say the least. I think we'd have to wait for more vulkan games to show up.

Check the 2nd video, it had Dota 2 results.

OP updated with image.

 

[eddman]

Check the 2nd video, it had Dota 2 results.

OP updated with image.

Yeah, very odd. Have you tried other drivers? Do you have another computer to test on?

The rendered numbers in heavy scenes are still below 480, right? So even without this bug, the overall framerate increase when going from opengl to vulkan is still quite low.

 

[Carfax83]

No it isn't, drivers still have to support Async Compute and Nvidia isn't providing working drivers. It's a "Fun Fact" that they still don't support Maxwell even though they sold them as supporting it.

If you read Ryan's GTX 1080/1070 review, then you'd know why Maxwell is unlikely to ever have asynchronous compute enabled. Pascal does however..

So? So does DX12 according to id.

DX12 was in development before Mantle, and was designed from it's inception to be capable of supporting multiple architectures. And while I have no doubt that AMD contributed heavily to DX12, it's not the same thing as them actually donating their entire Mantle codebase to Khronos Group.

So Nvidia needs to up their low level support to match AMDs?

Actually yes they do to an extent, especially for Vulkan.

And once again, waiting on async compute drivers from Nvidia. Wonder if it will be another "Fun Fact" that its still missing a month later.

Asynchronous compute is already enabled in NVidia's drivers for Pascal. ID still need to update Doom to recognize this function however.

Well considering they've worked directly with Nvidia for months, and Nvidia had them on stage to show off how well Vulkan ran trying to say they only spent time optimizing for AMD is absurd.

This is an intentional misquote, because I haven't said anywhere that ID only spent time optimizing for AMD. That is absurd.

What I am saying, is that AMD's infusion of Mantle into Vulkan gave ID a head start when it came to implementing low level optimizations for GCN. The addition of GCN intrinsic shaders is proof enough of that..

NVidia will eventually have their intrinsic shaders added to Vulkan as well via NVAPI..

 

[Elixer]

Asynchronous compute is already enabled in NVidia's drivers for Pascal. ID still need to update Doom to recognize this function however

What?
Vulkan has a API for this, it isn't AMD specific.
That is the whole point in using Vulkan, it is a standard API, this isn't a example of using custom libs (like gameworks), so, what exactly is Doom supposed to change?