AMD RX Vega 64 Outperforms NVIDIA RTX 2080 by up to 20% in Vulkan Enabled World War Z

[Sabrewulf...]

"World War Z is an AMD optimized title that makes use of the Vulkan API, which has borrowed many components from the company’s late great Mantle API. All of this means that it makes no surprise to see AMD’s Radeon graphics cards show stellar performance in World War Z. What is genuinely surprising however, is how that impressive performance translates to astonishing leads over the competition."

Source

Love me some Vulcan goodness! But is the game worth a shit or not?

 

[Pieter3dnow]

"World War Z is an AMD optimized title that makes use of the Vulkan API, which has borrowed many components from the company’s late great Mantle API. All of this means that it makes no surprise to see AMD’s Radeon graphics cards show stellar performance in World War Z. What is genuinely surprising however, is how that impressive performance translates to astonishing leads over the competition."

Source

Love me some Vulcan goodness! But is the game worth a shit or not?

Btw one of the links is more then misleading Mantle does not live on in Vulkan , Vulkan is an API that is based on the source code that was Mantle. To imply that Mantle itself lives on under a different name is far from the truth (when talking about Vulkan).

That the optimizations help AMD is a given but would it surprise anyone that Nvidia did not get the same treatment is why the difference is rather large?

 

[ManofGod]

Btw one of the links is more then misleading Mantle does not live on in Vulkan , Vulkan is an API that is based on the source code that was Mantle. To imply that Mantle itself lives on under a different name is far from the truth (when talking about Vulkan).

That the optimizations help AMD is a given but would it surprise anyone that Nvidia did not get the same treatment is why the difference is rather large?

The only thing I see is since they are unwilling to take the time to make DX12 games properly, for the most part, they should start going all in on Vulkan instead and start weaning off af DX11 already. Not our fault Nvidia's Vulkan implementation just is not as good.

 

[Riccochet]

Given that both new consoles coming out, PS and XBox, will be all AMD I'm betting we'll see a good number of future games based on Vulkan.

 

[sirmonkey1985]

Given that both new consoles coming out, PS and XBox, will be all AMD I'm betting we'll see a good number of future games based on Vulkan.

possibly since the current 3(besides the switch) are all amd based as well but don't support vulkan.

The only thing I see is since they are unwilling to take the time to make DX12 games properly, for the most part, they should start going all in on Vulkan instead and start weaning off af DX11 already. Not our fault Nvidia's Vulkan implementation just is not as good.

which also surprises me given how much money nvidia is putting into vulkan.

Btw one of the links is more then misleading Mantle does not live on in Vulkan , Vulkan is an API that is based on the source code that was Mantle. To imply that Mantle itself lives on under a different name is far from the truth (when talking about Vulkan).

That the optimizations help AMD is a given but would it surprise anyone that Nvidia did not get the same treatment is why the difference is rather large?

there's 2 versions of mantle.. there was the closer to metal mantle which forced microsoft to accelerate their release for dx12 and then mantle was transitioned to what eventually became a part of Vulkan we know now. how much of the original code is left who knows but the fact that they basically handed it over to Khronos group with no strings attached and that any hardware vendor can help support it was always going to be a game changer and you're seeing it more and more these days.

 

[/dev/null]

Looks like RX580 is preforming like GTX 2070, but I wonder how well it does under linux.

 

[Pieter3dnow]

there's 2 versions of mantle.. there was the closer to metal mantle which forced microsoft to accelerate their release for dx12 and then mantle was transitioned to what eventually became a part of Vulkan we know now. how much of the original code is left who knows but the fact that they basically handed it over to Khronos group with no strings attached and that any hardware vendor can help support it was always going to be a game changer and you're seeing it more and more these days.

Since then Vulkan took some big steps forward.

 

[Nolan7689]

Since then Vulkan took some big steps forward.

That aforementioned link goes to an article from 2015. I suppose back then it was more true that Mantle lived on in Vulkan.

It’s definitely misleading now though. 4 years is a long time for a engine to change and evolve.

 

[ChadD]

Its easy to appreciate how cool it was that AMD gave their mantel code to Khronos to kick start Vulcan. But ya at this point its a very different beast. AMD at the time could have given it all to Sony to help boost their Sony/AMD love fest and Sony could have used it for a next gen GNM Playstation API to make life difficult for MS and PC gaming in general. So good on AMD for being good open source team players.

IMO what this one game result highlights is the knife edge that is close to the metal APIs. IF there is a lot of support from the hardware manufacturer bare metal APIs CAN show massive performance boosts.... but they are very hardware specific. Those boosts may not translate and perhaps even cause performance penalties for other hardware... and even different generations of hardware. Its possible that things done at low level to push VEGA to its limit could end up hurting Navi performance. (if for instance it defaults to some FP16 over FP32 as an example... and later hardware like say Navi is capable of faster FP32)

For that reasoning for me I think more general Vulkan use with sparing use of bare metal code is the way to go... over heavily specific generation optimizations. Low level API use hasn't caught on in a big way and I think the main reason is most developers see a few major problems... first you need direct hardware info and support from manufacturers, and second those optimizations don't translate from AMD to NV to Intel, or even different generations of hardware from any of them.

I find it funny that 10 years ago all the talk was about High level languages that made it easier for more artist types to create art that could run on any complaint hardware with zero issue. (cause game artists are rarely highly talented code monkeys) Then gamers got caught up in the "low level is faster" hype. Sure Low level is faster but there is reason software is almost always written in some form of C and rarely written in Assembler.

 

[Derangel]

Given that both new consoles coming out, PS and XBox, will be all AMD I'm betting we'll see a good number of future games based on Vulkan.

Why would we? Sony uses a custom API and Microsoft will use a variation of DirectX.

 

[Mode13]

Why would we? Sony uses a custom API and Microsoft will use a variation of DirectX.

100% agree. Especially with Microsoft.

If Vulkan starts showing itself consistently to be better than DX, then maybe Sony would get the ball rolling by using it. Then MS would have to play catch-up, but they'll probably do that by launching some new lower level DX API. Unless MS are clinically stupid (which is possible) and are willing to have almost the entirety of PC gaming ripped from the mitts of their closed source proprietary MS only API...

 

[ChadD]

Why would we? Sony uses a custom API and Microsoft will use a variation of DirectX.

You know this generation... I have a feeling MS may finally cave on DX at least on the console. (perhaps... I mean I'm thinking 20/80 chances lol) For a few years now a lot of developers have been using Sonys tools and API first and then using Sonys tools to convert their code to DX. A lot of studios are already using Sonys ATF.... and the next generation will probably involve more changes to GDM and PSSL which will probably just pull Vulkan stuff in as the earlier stuff pulled Opengl.

If Sony releases a next gen version of ATF that basically supports all the Vulkan stuff in feature if not name... and continues to make it easy to convert that to DX if required later. I could see MS turning on some form of Vulkan support for developers. It might beat dealing with a year or two of Sony->DX conversions and PR about X or Y next gen launch title running better on Sonys PS5.

Then on top of that you have all the streaming stuff... a lot of AAA developers are going to be wanting Vulkan paths so they can move their games onto googles service as well.

MS has made some crazy open source announcements the last few years... it wouldn't shock me to much if they build Vulkan into their next console, as a secondary optional API for developers. Or heck they might even just EOL DX and make a real switch to Vulkan. MS is a Khronos contributer.. With everything else MS has done the last few years I wouldn't be shocked anymore if they announced a move to Vulkan and threw a pile of cash at them for more direct control.

 

[Mode13]

I'm pretty sure though that if Sony and MS (console) flip to Vulkan, that's going to be the death of DX on the PC. Every AAA game that requires a PC and console release isn't going to be ported between two APIs. That's why I think MS will hold on to DX until that day comes when Vulkan / Sony leaves them with no choice (support vulkan or lose AAA titles).

I wouldn't care though since Debian is my primary OS... I'd like to see more Vulkan titles and maybe even more linux binaries.. The death of DX would be a MASSIVE victory for the Linux Mustard Race

I find it funny that 10 years ago all the talk was about High level languages that made it easier for more artist types to create art that could run on any complaint hardware with zero issue. (cause game artists are rarely highly talented code monkeys) Then gamers got caught up in the "low level is faster" hype. Sure Low level is faster but there is reason software is almost always written in some form of C and rarely written in Assembler.

By today's standards C is a very low level language. For all practical purposes it's the lowest it gets.. It gives you access to memory which essentially makes it almost as capable as assembly. Also, it's impressive how optimized the object files produced by a modern C compiler are. I always read object files produced by my own C code just to learn new tricks in assembly, that's how good it can be.. You need to be very skilled in x86/64 to outdo GCC or similar. 10 years ago and now any programmer in need of ultra high performance would have went with C or C++. Assembly hasn't been needed heavily since the 90s and even then you really only used it for moving memory a word or double word at a time when ancient compilers like MS C/C++ would only move bytes, or very small assembly functions for ISRs...

I would imagine the artist types that are being forced to do some kind of programming are just given a C like interpreted language along the lines of a super modernized QuakeC.. There's absolutely no reason for an artist to be going near low level engine code.

 

[motomonkey]

I find it funny that 10 years ago all the talk was about High level languages that made it easier for more artist types to create art that could run on any complaint hardware with zero issue. (cause game artists are rarely highly talented code monkeys) Then gamers got caught up in the "low level is faster" hype. Sure Low level is faster but there is reason software is almost always written in some form of C and rarely written in Assembler.

Reminds me of the programs we used to get in magazines for the C64 a solid page of assembler, in tiny tiny close spaced font, carefully type it all in and hope you caught all the mistakes. There were some really decent programs shipped like that.

 

[ManofGod]

The only thing I see is since they are unwilling to take the time to make DX12 games properly, for the most part, they should start going all in on Vulkan instead and start weaning off af DX11 already. Not our fault Nvidia's Vulkan implementation just is not as good.

By the way, this is not an endorsement for multiplatform from me.

 

[RanceJustice]

Looks like RX580 is preforming like GTX 2070, but I wonder how well it does under linux.

I wouldn't be surprised if it was the same or better. Typically, recent AMD cards (ie 500 series and especially Vega) run even better on Linux than they do on Windows thanks to an improved driver stack. AMD went out of their way to create a new Linux driver stack from the ground up, with 90% of it being open source! The other 10% is not a separate proprietary driver but something of a "proprietary plug-in" atop the open source base. This is particularly notable with OpenGL for instance, as AMD's OpenGL performance (older than Vulkan) is reasonable but limited compared to NV - on Windows! However, on Linux OGL is FAR better on AMD cards thanks to drivers - this is evident with some emulators like Cemu (and I think Yuzu , Citra ) that don't yet have Vulkan support but run OGL instead. I'd really be curious to see how far the Radeon VII outperformed the RTX 2080 and how it stacked up to the 2080 Ti

This is just more reason why we should generally buy AMD - their support of openness means better experiences coded better for everyone. There's a lot of "cheating-type or proprietary optimization" for Intel CPUs, Nvidia GPUs etc.. in some titles, but if everything was optimized to standards for GPU and CPU alike we'd all be better off with more consistent performance; AMD isn't always perfect but they're generally a hell of a lot closer to this for both components than the competitors.

 

[Pieter3dnow]

For that reasoning for me I think more general Vulkan use with sparing use of bare metal code is the way to go... over heavily specific generation optimizations. Low level API use hasn't caught on in a big way and I think the main reason is most developers see a few major problems... first you need direct hardware info and support from manufacturers, and second those optimizations don't translate from AMD to NV to Intel, or even different generations of hardware from any of them.

Remember how Battlefield 4 ran on Mantle , but that was not the whole story everything that ran on that Frostbite engine ran in Mantle plants vs zombies, dragon age inquisition and some others...

It depends all on long term plans for API usage.

I have some doubts about the statement that the optimization don't translate. There is nothing stopping anyone from making those rather then suggesting that they only work for AMD and that is a far cry from the problems where Nvidia just clogs tessellation or starts doing blackbox where they choose which AMD instructions to use. All of the Vulkan stuff is above board....

 

[Auer]

So 'splain to me..why this big difference in WWZ vs. a much much closer performance between Nv and AMD in NMS that just recently got Vulkan?

NMS players report huge gains for AMD users and very minor negative gain for NV after the switch from OpenGL. Before that AMD cards really struggled in NMS with OpenGL.

 

[Nolan7689]

So 'splain to me..why this big difference in WWZ vs. a much much closer performance between Nv and AMD in NMS that just recently got Vulkan?

NMS players report huge gains for AMD users and very minor negative gain for NV after the switch from OpenGL. Before that AMD cards really struggled in NMS with OpenGL.

I think you answered your own question. NMS and AMD cards just don’t get along regardless of the API.

 

[Dr. Righteous]

The only thing I see is since they are unwilling to take the time to make DX12 games properly, for the most part, they should start going all in on Vulkan instead and start weaning off af DX11 already. Not our fault Nvidia's Vulkan implementation just is not as good.

Here is the deal;
Vulkan is cross platform; DX12 is proprietary to windows. Which is the win for the consumer and developer at the same time? This will be deciding factor on which API flourishes and which one fades.

 

[Snowdog]

Here is the deal;
Vulkan is cross platform; DX12 is proprietary to windows. Which is the win for the consumer and developer at the same time? This will be deciding factor on which API flourishes and which one fades.

Cross platform to what? Linux? In a very practical sense DX12 is more cross to a gaming platform that matters: Xbox.

 

[Dr. Righteous]

Cross platform to what? Linux? In a very practical sense DX12 is more cross to a gaming platform that matters: Xbox.

Windows, Linux, Android,MacOS,iOS,WebOS, Nintendo Switch, plus the new generations of consoles that will use AMD APUs. All the gaming engines (that matter) support it already.

 

[Derangel]

Windows, Linux, Android,MacOS,iOS,WebOS, Nintendo Switch, plus the new generations of consoles that will use AMD APUs. All the gaming engines (that matter) support it already.

And this generation of Sony and MS consoles used AMD APUs as well. Why do you think that changes anything? Sony has ALWAYS used their own custom APIs for consoles and MS uses DX.

 

[DooKey]

I suspect NV Vulkan performance will increase over time as the developers tweak for the architecture. This is an AMD sponsored title after all.

 

[Dr. Righteous]

And this generation of Sony and MS consoles used AMD APUs as well. Why do you think that changes anything? Sony has ALWAYS used their own custom APIs for consoles and MS uses DX.

Vulkan will dominate because developers can maximize sales if their game is release for several platforms at once. Using 1 cross platform API in development beats the hell out of having to use a different API for each platform.

 

[Derangel]

Vulkan will dominate because developers can maximize sales if their game is release for several platforms at once. Using 1 cross platform API in development beats the hell out of having to use a different API for each platform.

How did that work out for OpenGL? Vulkan does not work on current consoles and unless Sony and MS make massive changes to how they operate it will not work on the PS5 and next Xbox either. The vast majority of console and mainstream PC devs don't make games for Linux or mobile phones as it is so an API supporting those doesn't mean much unless they decide to change the platforms they develop for.

 

[ChadD]

Remember how Battlefield 4 ran on Mantle , but that was not the whole story everything that ran on that Frostbite engine ran in Mantle plants vs zombies, dragon age inquisition and some others...

It depends all on long term plans for API usage.

I have some doubts about the statement that the optimization don't translate. There is nothing stopping anyone from making those rather then suggesting that they only work for AMD and that is a far cry from the problems where Nvidia just clogs tessellation or starts doing blackbox where they choose which AMD instructions to use. All of the Vulkan stuff is above board....

Don't get me wrong I'm not suggesting the low level optimizations are not above board or something.

Just think of it this way.... look at say Nvidias Turing Tensor units. They added the ability to do lower precision math FP16 even FP8. Software that used the low level Vulkan optimizations for Volta would have perhaps split 64bit math up to 32 bit but not the lower precision. If the software was simply coded to a high level tensor language the Vulkan compiler would get that new information from the driver and potentially render it lower with out the developer ever getting invovled in the process with a direct update. That type of driver optimization... where a manufacturer adds compiler options and informs them when to use them happen with pretty much every new generation of card. When AMD adds a few new things to something like VII their drivers will inform things like the Vulkan shader compiler that they have a few new tricks to use in cases of X or Y. (low level code often skips that compile) Again going back to C and Assembler... if you program something in Assembler and then add a bunch of new C compile features that could do what you did in Assembler last year better recompiling won't help as the code is still in assembler.

With High level code the API and Driver can shake hands as it where on the new way of doing it faster. However if the developer coded some lower level specific instructions like RUN at FB32 for this this and that... its still going to do exactly that ignoring all the new generations potential. (unless the developer releases a patch for X new generation that implements that new way of doing things).

That is the main issue for developers. If you go super low level your going to have to go back and patch for new hardware all the time. Specific operations intended to run best on X or Y card will sure work on other cards but it might not be the best way... where as high level code will. SO sure low level is no doubt potentially the fastest best code around... but its specific, and needs to be updates as hardware changes. High level code does not need that level of hand holding... the API itself has a compiler and high level is still the easiest way to support ALL current hardware and all future hardware. (this story is a case where the specific low level optimizations favor AMD but in most cases its NV throwing around the money at developers and the reverse is often the case)

So IMO yes game developers should be using HLSL as often as possible. Let the Vulkan compiler do the work. C code written in 1990 can be compiled today for current generation hardware and run as well as code written yesterday. Assembler code from 1990 is pretty much useless unless your machine is from 1990.

 

[Dr. Righteous]

How did that work out for OpenGL? Vulkan does not work on current consoles and unless Sony and MS make massive changes to how they operate it will not work on the PS5 and next Xbox either. The vast majority of console and mainstream PC devs don't make games for Linux or mobile phones as it is so an API supporting those doesn't mean much unless they decide to change the platforms they develop for.

Vulkan is a all new API and has nothing to do with OpenGL and it share NO coding at all. OpenGL is legacy coding from the days of the long defunct Silicon Graphics.
If you were somehow missed the development of Vulkan the genesis started with engineers at AMD that were frustrated because it was well known that legacy API (OpenGL and Directx) drastically limited performance thus and was bring gaming development to a stand still. So bright minds at AMD developed MANTEL. which was to demonstrate a light weight API with "direct to metal" coding would easily outperform legacy graphics APIs. AMD turned over MANTEL to the Khronos Group to continue development into a cross platform modern API; that is what became VULKAN. Sony has nothing to lose by adopting Vulkan neither does Windows and it is a win-win-win for every player in the game.

 

[Derangel]

Vulkan is a all new API and has nothing to do with OpenGL and it share NO coding at all. OpenGL is legacy coding from the days of the long defunct Silicon Graphics.
If you were somehow missed the development of Vulkan the genesis started with engineers at AMD that were frustrated because it was well known that legacy API (OpenGL and Directx) drastically limited performance thus and was bring gaming development to a stand still. So bright minds at AMD developed MANTEL. which was to demonstrate a light weight API with "direct to metal" coding would easily outperform legacy graphics APIs. AMD turned over MANTEL to the Khronos Group to continue development into a cross platform modern API; that is what became VULKAN. Sony has nothing to lose by adopting Vulkan neither does Windows and it is a win-win-win for every player in the game.

OpenGL was multiplatform as well, that was my point in bringing it up. I thought that would have been blindingly obvious.

"Nothing to lose" outside of not being able to create a custom API that specifically takes advantage of their hardware in order to make things easier for developers. Even DX on Xbox is customized to suit the console. In order to do that with a 3rd party API they would either need to get engineers from Khronos (and likely have to pay a lot of money to do so) to come in and help customize Vulkan for their system or they would have to retrain their entire API team to use Vulkan and do the customization in house. At that point, its easier to just use in-house tools and APIs. If Sony and MS come out and say "we're supporting Vulkan on our consoles" feel free to tell me I was wrong, but I just don't see it as anything more than a pipe dream at this point.

 

[Nolan7689]

Sony has nothing to lose by adopting Vulkan neither does Windows and it is a win-win-win for every player in the game.

Sony has nothing to gain. They have their own low level close to the metal API for their console already. Why spend the resources implementing Vulkan?

Similar Microsoft has DirectX. It is their own proprietary API. It doesn’t make sense for them to say “We’re done with what we created now we’re using Vulkan instead” and similarly to Sony’s API their console DX has sometimes been modified to work better with the hardware. I think OG Xbox used vanilla DX to go with its rather vanilla PCparts hardware, and Xbox One is DX12 seeing as how MS attempted to make DX12 much closer to the metal than previous versions. At which point the argument for Vulkan helping between PC/Console applies to DX12 games on the Xbox as well.

 

[mvmiller12]

OpenGL was multiplatform as well, that was my point in bringing it up. I thought that would have been blindingly obvious.

"Nothing to lose" outside of not being able to create a custom API that specifically takes advantage of their hardware in order to make things easier for developers. Even DX on Xbox is customized to suit the console. In order to do that with a 3rd party API they would either need to get engineers from Khronos (and likely have to pay a lot of money to do so) to come in and help customize Vulkan for their system or they would have to retrain their entire API team to use Vulkan and do the customization in house. At that point, its easier to just use in-house tools and APIs. If Sony and MS come out and say "we're supporting Vulkan on our consoles" feel free to tell me I was wrong, but I just don't see it as anything more than a pipe dream at this point.

Half right.

Getting specific custom HW extensions to the VULKAN API is not that big of a deal. Especially compared to the expense and complexity of creating an entirely new API from scratch with every HW iteration. No. Sony will stick with their custom APIs BECAUSE they have a hot console that people want. It is not in their interest to make porting to the competition easier for developers; their care is to their own shareholders and locking people into their platform. The vast majority of gamers don't know (and don't give a shit) about APIs or game "development" in general; they just want fun games. Developers will STILL develop for Sony as long as people keep buying Sony and Sony has the mindshare to make that happen. Much like when AMD has classically had a superior product to Intel or nVidia (and at various times, they have) and the masses still bought the Intel or nVidia parts anyway - they have the mindshare.

We enthusiasts that know and embrace this stuff - we're not even a drop in the bucket.

 

[ChadD]

OpenGL was multiplatform as well, that was my point in bringing it up. I thought that would have been blindingly obvious.

"Nothing to lose" outside of not being able to create a custom API that specifically takes advantage of their hardware in order to make things easier for developers. Even DX on Xbox is customized to suit the console. In order to do that with a 3rd party API they would either need to get engineers from Khronos (and likely have to pay a lot of money to do so) to come in and help customize Vulkan for their system or they would have to retrain their entire API team to use Vulkan and do the customization in house. At that point, its easier to just use in-house tools and APIs. If Sony and MS come out and say "we're supporting Vulkan on our consoles" feel free to tell me I was wrong, but I just don't see it as anything more than a pipe dream at this point.

Both MS and Sony are involved directly with the Khronos group. They give them plenty of $$$ every year. They are free to submit new extensions. Neither has to do that as neither are hardware vendors. AMD Nvidia Intel ARM SI and all the other hardware members DO submit new extensions all the time that expose features on their hardware. As an example both Nvidia and AMD have submitted extensions to expose real time ray tracing, first AMD with their Radeon Rays stuff and now NV with their extensions.

The only real difference between Sonys GNM APIs MSs directx and OpenGL/Vulkan is who has final say on what goes in. Having said that Khronos has never no noed anything I'm aware of as far as extension submission. Sony likes to keep GNM so they can make development tools that are locked into their PS hardware... if they supported OpenGL directly (even thought GNM is basically just rebranded OpenGL) developers could easily focus on more general hardware. (which is not really what Sony wants PS developers doing) For MS they have a long history of holding new extensions for all their APIs so they can drop themselves and benefit with first to market software first.

So the reasons Sony and MS would want to stick to what they are doing are selfish ones. For gamers we would all be better off if game developers and hardware manufacturers pushed hard to get both of them out of the middle of the stack.

What might be different toady is how many tools and how much easier it is to port DX Opengl GNM Vulkan back and forth. The old advantages of locking developers to your hardware... and holding big features for big rollouts are less now then they have ever been. So I think we may be at a point where MS for sure and potentially Sony both see adoption of the open standard Vulkan as being much cheaper then continuing to develop their own things. (same reasoning I use when I argue that its only a matter of time before MS windows uses the Linux kernel)

Vulkan is to graphics as Linux is to kernels. You can develop your own thing but your basically competing against everyone else. So even if your the #1 guy with 3x the RND budget... your still the less developed X as EVERYONE else is pulling together against you. Better to become part of the fold submit your specific changes and inclusions to share... and benefit from everyones work in return. It works for Linux... and in hopefully its going to work for Vulkan. Khronos got rid of all the legacy OpenGL stuff and all that baggage... and hopefully the industry will get behind Vulkan as a true collaboration.

 

[Deleted member 243478]

Windows, Linux, Android,MacOS,iOS,WebOS, Nintendo Switch, plus the new generations of consoles that will use AMD APUs. All the gaming engines (that matter) support it already.

iOS using AMD hardware? What? Bahahahaahah

 

[Dr. Righteous]

iOS using AMD hardware? What? Bahahahaahah

Apple refused to support Vulkan so the Khronos group created a SDK for Vulkan on iOS. It works and works well and is much faster than Apples implementation of OpenGL.

 

[N4CR]

So 'splain to me..why this big difference in WWZ vs. a much much closer performance between Nv and AMD in NMS that just recently got Vulkan?

NMS players report huge gains for AMD users and very minor negative gain for NV after the switch from OpenGL. Before that AMD cards really struggled in NMS with OpenGL.

No they had the performance lead from launch and Nvidia cards had issues. Later on that changed a bit though. In this case Vulkan just makes use of the additional performance available in the architecture that might not be available in DX/OGL/gimpworks etc overhead. Same happened with Doom and it took a while for Nvidia to get off their ass and catch up.

Funny thing about this one though is it's really looking game ready and the way it's meant to be played!