Its more than that - Open GL is perfectly fast and smooth but with Vulkan something is causing CPU frametimes to spike constantly - how badly seems to vary from setup to setup and is worse on 368.69 versus 368.81 driver.
-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
Doom Vulkan vs Open GL performance
- Thread starter Doom112
- Start date
Its more than that - Open GL is perfectly fast and smooth but with Vulkan something is causing CPU frametimes to spike constantly - how badly seems to vary from setup to setup and is worse on 368.69 versus 368.81 driver.
Some 980Ti screens from similar terrain in that video. No waiting for textures to load in or anything I noticed at least. The last screen had some weird shimmering effect depending how closely I moved to it...
Make of them what you will, 1440p, Ultra pre-set
Make of them what you will, 1440p, Ultra pre-set
also you need to consider that Nvidia need to provide/work further for the tools the Devs need to have for a closer access to the hardware, vulkan already uses parts of Mantle's library for AMD, Nvidia will patch these issues, and vulkan support will get better for them overtime, AMD just got couple years of work already implemented in vulkan.
I played and completed DOOM a week before the Vulcan drivers were released. I felt no fps issues unless playing for a few hours but reloading the game fixed it. Memory leak perhaps.
When Vulcan came out I switched to it but didn't actually start playing until yesterday and it was a struggle it was easy to see it was laggy and I was having a hard time dying a lot because I'm also now playing on nightmare. So I figured because I previously played on an easier difficulty and wasn't dying I didn't notice the FPS possibly being choppy.
Now I saw this thread and see people getting 30 to 50fps increase. I never measured my FPS before or after so for the last 10 minutes I've been doing that and the results follow.
OpenGL 4.5 = 70 to 75
Vulcan - 35 to 38
Some people have doubled their FPS with Vulcan but mine has halved. I'm using an i7 930(Bloomfield), GTX 780 and 6Gb RAM.
When Vulcan came out I switched to it but didn't actually start playing until yesterday and it was a struggle it was easy to see it was laggy and I was having a hard time dying a lot because I'm also now playing on nightmare. So I figured because I previously played on an easier difficulty and wasn't dying I didn't notice the FPS possibly being choppy.
Now I saw this thread and see people getting 30 to 50fps increase. I never measured my FPS before or after so for the last 10 minutes I've been doing that and the results follow.
OpenGL 4.5 = 70 to 75
Vulcan - 35 to 38
Some people have doubled their FPS with Vulcan but mine has halved. I'm using an i7 930(Bloomfield), GTX 780 and 6Gb RAM.
Kepler cards are doing very badly in Vulkan tests so far, they're all over the place performance wise.
Looks like it's most likely a driver issue, have you check to see if you have the latest drivers? NVIDIA were apparently working on a new Vulkan performance one.
There is another driver out yeah, came out on the 14th. Installing it now, once it's done I'll test Vulcan again.
[EDIT] New driver installed and it's better but still not as good as OpenGL. In the stretch of corridor I'm running around Vulkan holds up well around 60fps where OpenGL is 70fps but stepping through the door into a fight Vulkan tanks to 35ish where OpenGL is 50 to 60fps. I'm near the start of Argent Tower in the corridor after the first rune trial with 2 pentagrams on the floor.
Last edited:
Yeah saw a 22% increase in performance in Vulkan with 368.81 v 368.69 on my 780 but that is still 10-15% behind my Open GL numbers and not as smooth either - the numbers are cycling up and down the equivalent of 2x vsync multipliers despite vsync fully disabled (even tried without gsync) which IMO isn't coincidence (but I think the problem is more than just a buggy vsync implementation which is probably also the case).
Soldato
Streaming of textures hardly constitutes the sensationalist idea you are getting a 'visually inferior' experience on an Nvidia card.
Soldato
Texture streaming is an awful visual experience. Totally destroys immersion in the game 
Soldato
Wolfenstein and RAGE drive nuts with texture streaming. I really would like to know why it is seen as a good tech when it creates such a visual annoyance.
Anywho... does this happen only with OpenGL or Vulkan, or both tech's?
Anywho... does this happen only with OpenGL or Vulkan, or both tech's?
Caporegime
Completed the first level in 13 minutes, skipped the part at the start where you sit through the boring dialogue with Mr Hayden.
Doom Vulkan | Radeon Pro Duo | 1080P - Ultra Settings | Resource Operations
Last edited:
Associate
That cpu usage... mmmmmmmmmmmmmmm delicious
Caporegime
Megatextures are great tech, issue is it needs a lot f bandwidth and memory to work correctly and actually run at high res.
It looks great once loaded and doesn't need to load again usually as it does so for the entire map; but, yeah some cards just don't like it and that horrible texture stream kills the fun. Although Unreal 3 was pretty bad for it as well until that engine got polished a lot.
As far as I could tell from the video and other comments this was checked using OpenGL. No idea if it happens in Vulkan though, but the older Kepler cards have even more issues with Vulkan besides a texture stream issue.
It requires either very high bandwidth OR true parallel async compute.
I have not programmed this sort of thing yet, but from what I've read the following seems quite a reasonable explanation to me:
AMD cards use the copy queue to stream the textures while compute/3d queues are still doing actual graphics work (in parallel). NVidia cards can't copy in parallel and must do their preemption thing to implement the async behavior (i.e. pause transfer to render frames). Therefore it follows that this effect will appear when the memory bandwidth is not high enough to complete the data transfer within the time-slices NVidia allocates to copying.
In short, memory bandwidth for NVidia cards becomes more important, whereas AMD cards can get away with lower bandwidth as long as they start transferring textures in time.
I assume NVidia can fix this on 1070 by changing the driver to prioritize copying a bit (at the cost of some lower FPS during that time). Or the developers can tune this manually to get the 1070 to work perfectly. But it's just too time-consuming to do this for every single card. For example, the 1080 using the faster GDDR5X seems to be fast enough and is totally unaffected. Tuning a path for 1070 would cause the 1080 to take an FPS hit for no reason. So you need 2 different paths as a dev to get both working optimally? And what about the other models?
I don't thing people realise the importance of this. Sure 1-2 secs of worse image quality on the 1070 is not a big deal (seriously, who cares?). However, this is the kind of thing that makes tuning for AMD so much easier.
Multi-engine is hard enough already, even without having to worry about all this. In AMD cards you can just schedule whatever you need and let the ACE figure out the scheduling, not having to worry so much about every single detail. Whereas NVidia needs devs to put in time and tune these operations manually or has to do it themselves by game profiles in their drivers (not sure how well the latter will work but that's what NVidia keeps saying: we will address this stuff in software).
I find it interesting that the basic premise of devs going forward is now: 'worry about getting NVidia to work acceptably as AMD cards will sort themselves out'. For example this DX12 dev guide (yes I know Doom is Vulkan but the multi-engine paradigm is the same among the two) actually goes as far as to spell it out:
* Choose sufficiently large batches of short running shaders.
Long running shaders can complicate scheduling on Nvidias hardware. Ensure that the GPU can remain fully utilized until the end of each batch. Tune this for Nvidias hardware, AMD will adapt just fine.
Long running shaders can complicate scheduling on Nvidias hardware. Ensure that the GPU can remain fully utilized until the end of each batch. Tune this for Nvidias hardware, AMD will adapt just fine.
NVidia is getting into an age where they will have minor quirks like that all over the place and will rely on its mindshare for users to 'tolerate' this while they sort it out in drivers. At the same time developers will have less and less incentive to profile every single NVidia card model and to get it to work acceptably. They will choose a baseline (and I hope it's the 1060 so that things work for most users) and tune for that minimum (lower models will have degraded quality while higher models may take a bit of an FPS hit).
I really want to see how well the 1060 with its 192bit bus will cope with these scenes in Vulkan mode. It may make the problem much more visible which would confirm my suspicions (i.e. they optimised Doom for a 1080 which makes the 1070 suffer and the 1060 suffer even more).
Caporegime
Completed the first level in 13 minutes, skipped the part at the start where you sit through the boring dialogue with Mr Hayden.
Doom Vulkan | Radeon Pro Duo | 1080P - Ultra Settings | Resource Operations
Is anyone still interested in seeing these benchmark videos or are we balls deep in API debate?
I could run some 1080P/1440P footage on a RX 480 for comparison purposes, if there is any interest in seeing performance under Vulkan?
I could run some 1080P/1440P footage on a RX 480 for comparison purposes, if there is any interest in seeing performance under Vulkan?
I'd be interested in this.
I could run some 1080P/1440P footage on a RX 480 for comparison purposes, if there is any interest in seeing performance under Vulkan?
I would be interested in this too. Thanks Matt.
Caporegime