Vulkan API: It’s Gaming, Jim, But Not As We Know It

One API to rule them all. Wrong fantasy franchise, perhaps, but that’s the idea behind Vulkan, the snazzy open-source successor to OpenGL, alternative to Microsoft’s DirectX and something that might shake up gaming on everything from PCs to phones. But what’s an API? And why should you care? We’ll come to that. For now, if Vulkan is everything it’s cracked up to be, it’ll make games run faster and look better on your existing PC. It might make that SteamOS thing a goer, too. Anyway, version 1.0 is out, so the chattering weberati will be casually trading Vulkan references to prove their PC gaming prowess. Time to bone up. Plus I’ve just sat through a five-hour keynote stream on Vulkan from GDC 2016. So humour me. This stuff is actually quite interesting.

– Vulkan is an open source alternative to Microsoft DirectX on the PC
– It’s the successor to OpenGL
– But it’s derived from AMD’s Mantle API
– It’ll be on everything from phones to PCs
– Like DirectX 12, it claims to make games run faster
– It won’t cost you anything
– It’ll run on AMD graphics cards right back to Radeon HD 7000 series and Nvidia GeForce 600 series boards and newer
– A driver update is all you’ll need
– Oh, and it might make Valve’s SteamOS a viable gaming platform

Let’s begin by elbowing the question of what an API is into touch. It stands for Application Program Interface. And it’s just that. An interface between bits of software.

In practice, an API provides building blocks and tools that make it far simpler for developers to achieve a working application. If we’re talking graphics – and we are indeed talking graphics – then the API is the interface that connects your games with your graphics driver. And thus the 3D visuals are rendered.

The advantages of this approach are pretty profound. With a graphics API, it’s possible to have (mostly) one set of game code that will run on any hardware that’s compliant with the API. So, a game is coded for, say, DirectX 9 and any graphics card that’s DirectX 9-compatible will run it. In theory, anyway. In practice, it’s usually a bit more complicated.

So using an API means that game developers don’t need to be world authorities on both Nvidia and AMD graphics chips, for example. They can use the tools provided by the API and let Nvidia and AMD do the heavy lifting through the driver.

It’s also worth understanding that APIs come in different flavours, otherwise known as high- or low-level abstraction. That sounds fancy, but the implications are pretty straight forward. The higher the level of abstraction, the more distant the application becomes from the specifics of the hardware and the greater the workload handled by the API and graphics driver (in this case).

All aboard the Vulkan train

That’s good in the sense that it makes games development simpler in some ways. The downsides include the need for extensive optimisation jiggery pokery via drivers and in turn fewer opportunities for developers to get things really flying.

As things stand, DirectX has largely been quite a high-level API. It just so happens that DirectX has also been pants when it comes to CPU overheads and multi-threading. And that’s meant DirectX games have been pretty pants by both metrics. And developers often haven’t been able to do much about all that.

Enter a new age of low-level APIs that aim to solve these problems. Arguably, it all started with AMD’s proprietary Mantle API. At the very least, it seems like Mantle bucked up Microsoft’s ideas, leading to DirectX 12 and promises of much reduced CPU overheads and improved multi-threading.

And now we have Vulkan, brought to you by Khronos, the industry consortium behind OpenGL. Fair to say that OpenGL had conspired to become messy, inefficient, unloved, stagnant and left behind for serious PC gaming.

The idea was a clean break from OpenGL, a total reboot. Key features and aspirations for Vulkan include addressing all those nasties mentioned above – so that’s reduced driver overhead, low CPU overhead, better use of multi-core CPUs.

If you want to get more detailed, Vulkan’s low-level API status means games will have more control over their own destiny in terms of performance. Games rather than the API and driver will handle memory allocation and thread management under Vulkan.

As it happens, one of Oxide games graphics gurus, Dan Baker, reckons these aspects will be critical. He says it turns out that memory bandwidth and latency are the big issues for CPU performance in games, not number crunching. So the ability for developers to fine tune things will make a huge difference.

As for threading of games, Baker says with Vulkan, everything becomes hyper granular. In other words, instead of big, heavy threads, a typical game frame will contain 50-100 tiny rendering jobs. And those can be very efficiently load balanced across as many cores as your CPU can offer.

All a simple matter of syncing command buffers in the command queue…

Of course, like OpenGL, Vulkan isn’t tied to one platform. It’ll be on PC in both Windows and Linux. But it will also be in Google’s Android OS (I believe in an updated version of Marshmallow, for those who care). In fact, all the big names have (at least ostensibly) thrown their hat into the Vulkan ring on some level. AMD, Nvidia, Oculus, Nintendo, EA, Oxide, Sony, Lucasfilm, you name it. The only obvious omission at this stage is Apple, which is going it alone as ever with its Metal API.

It’s also worth noting that Vulkan won’t be limited to Windows 10, like DirectX 12. It’ll be supported right back to Windows 7. That could be critical to encouraging uptake of Vulkan by developers – the knowledge that a Vulkan code path gives them access to a fast, low-level API beyond just Windows 10 and DX12.

Oh, and Valve. Did I mention Valve? Vulkan seems purpose built to put Linux-based SteamOS back on the map as a gaming platform. Up to now, SteamOS’s prospects have looked patchy at best. A lot of that was thanks to poor graphics drivers in Linux and the laggardly state of OpenGL.

In theory, Vulkan solves both of those problems. Drivers will be far less critical for performance. And it will be feature and performance competitive with DX12 as an API. Plus, once you have a Vulkan codepath, knocking out versions for both Windows and Linux ought to be straight forward.

Moreover, the big boys of the PC game engine jungle seem to be pro Vulkan – Unreal from Epic, Valve’s Source 2 and Frostbite from Dice are all going to support Vulkan and that should mean it’s straight forward for game developers using those engines to also support Vulkan.

That said, one of the unknowns is just how big an impact all this will have on developers generally and how keen they will be with the new work loads. Vulkans gives them more opportunities. But it also creates new work and puts much more onus on them when it comes to ensuring good performance.

Games with lots of stuff going on, like Ashes of Singularity, are the go-to titles for demonstrating the advantages of new low-level APIs like Vulkan

Which brings us to probably the most controversial aspect of Vulkan. AMD donated the Mantle API in its entirety to the Khronos consortium. At its core, Vulkan is derived from AMD’s Mantle API.

At this stage, it’s impossible to say how influential this single fact will be to its long term prospects. It’s easy to see how that could be interpreted as a killer advantage for AMD hardware and how, in turn, Nvidia wouldn’t want to touch the thing.

In practice, insiders say much of Vulkan has been rebuilt. What’s more, Nvidia actually beat AMD to releasing a fully compliant and tested Vulkan driver.

Right now, there’s little to nothing you can play to give Vulkan a go. There’s the Talos Principle, but it apparently doesn’t run terribly well. There’s a guide here for getting it going if you really must.

Obviously an awful lot of this is fairly speculative at this early stage. Just how keen will developers be? Will Vulkan’s AMD roots be a long term issue? Will Vulkan on Android make the slightest difference to its success on the PC?

Who knows, but the theory all makes sense. So it’s all to play for. But at least now you know what it’s all about.


  1. tannerd says:

    “Unity from Epic” Unreal, surely?

  2. Author X says:

    Thanks for the article, it’s good to have a grasp of what it actually means when low-level tools like this are announced, and you did a good job explaining how it’s important and how it’s different from DirectX and OpenGL.

    Though I think you mixed up Unity and Unreal Engine in one bit, “Unity from Epic” (from the logo swarm it looks like both are on board anyway).

  3. craigdolphin says:


    And good. May not need to ever go to Win 10 just to get DirectX12.

    • Cinek says:

      You still likely will. DX12 games don’t run on Vulcan unless specifically implemented, which is relatively rare, and there’s more games for DX12 planned than Vulcan. Also DX12 by all means seem to be a better performer than Vulcan, pretty much only advantage Vulcan has is its openness.

  4. TillEulenspiegel says:

    It just so happens that DirectX has also been pants when it comes to CPU overheads

    Sort of. The problem is a little more fundamental than wasted CPU cycles.

    It’s that high-level APIs usually don’t map perfectly on to how the hardware actually works. Now after a couple of decades of serious GPU development, it makes sense to design a new API which does in fact closely resemble the way all modern GPUs work.

    • DFX2KX says:


      DirectX is basically a distant descendant of DirectDraw, and that predates Windows 95, if I recall correctly (think it showed up in one of the later 3.1 versions).

      3D acceleration didn’t even EXIST. Ditto for Shaders. And for the longest time even after that, to use any of the built-in shaders that ATI, Voodoo (or later Nvidia) had, you had to start factoring in individual video cards. (There where a few games that where DirectX, but didn’t work on cards of one or more manufacturers for this reason. Team Apache comes to mind)

      From what I understand, the 3D APIs I mess around with are worlds better then what you had back in the day.

      • Kaldaien says:

        Pixar invented shaders in the 80s, iD software brought them to PC gaming with the Quake engine and later NVIDIA finally got around to bringing them to actual hardware. Some of the series of events here is revisionist, I would say? :P

  5. Sp4rkR4t says:

    I really hope Vulkan becomes the default api to build PC games considering Microsoft’s repeated mis-steps with windows the faster PC gaming becomes OS agnostic the better.

  6. Jakob91 says:

    It’s the best gaming news I heard in the last 15 years. Yep.. I never liked M$ forcing gamers to change OS with fake promises. I remember when they tried to scrap PC gaming when the first xbox came out, I remember Windows Vista with it’s exclusive and revolutionary DirectX10, I remember GFWL that requires an additional account with it’s amazing cloud save feature that vanishes in thin air when it feels to.
    Let’s face it, it’s mostly Valve that saved PC gaming and although I probably won’t have SteamOS, I’ll have the choice for an alternative to the enclave which is(was) windows10 now that there’s a real alternative to DirectX. Thank you.

    • xyzzy frobozz says:

      SteamOS will be fine, so long as you only want to run games.

      Whereas you can run games and all of your other stuff in Win.

      I really see no future for SteamOS as anything but a place for game playing I-hate-M$-for-minor-and-poorly-thought-out-reasons hipsters.

      • Christian Dannie Storgaard says:

        Oh, you can run your programs in SteamOS as well, it comes with a desktop mode. However, I think the more relevant use of SteamOS is as a Linux reference platform; if it works on SteamOS, a publisher can call it a day and leave it to the other distributions (Ubuntu, Debian, Fedora, Arch, etc.) to handle any issues that may come up there.

        • Mokinokaro says:

          Unfortunately, this is not the case.

          Some indie devs have complained that SteamOS uses non-standard versions of a lot of Linux libraries, meaning some games compatible with other flavours of Linux won’t work on it and vice versa.

          • DFX2KX says:

            I’ve heard that as well. Even with Ubuntu. That is something Valve really aught not to have done, because I can’t for the life of me figure out why it was necessary.

            That being said, getting a SteamUS game running in RedHat or Ubuntu isn’t going to be nearly as much work as getting it to run on a nix platform in the first place. Still annoying, though.

      • zagibu says:

        You can both run regular programs on SteamOS and run games certified for SteamOS on regular Linux distributions.

      • Nouser says:

        Steam OS tries to be an alternative to somewhat limited console OSes like the tuned BSD of the PS4 or the modified Windows of the Xbox One, not a complete desktop operating system.

        If you want a desktop OS, there are other Linux distributions more suited for that. Which, by the way, can also run the same games that Steam OS.

      • baltasaronmeth says:

        SteamOS is just the standard platform for Steam on Linux. If you have trouble running a game on your distribution, you find out how SteamOS solves it and implement the fix on whatever system you are. This is true for both users and package maintainers.

      • WyldFyr says:

        I used to be a M$ hating hipster, except I was never “hip”. These days though I have my hate cannon aimed elsewhere, now that it seems MS has finally given up its bid to rule the world.
        Apple, I’m watching you!… grrr… apple pay, grrrrrrr….

    • waltC says:

      I think the *one* game out now that supports Vulkan to any extent whatsoever supports it with a wrapper, so drivers from the IHVs are extremely premature at this point in time and basically a matter of marketing as opposed to substance. Think of Vulcan as OpenGL on steroids, though…far, far better than the ancient OpenGL version used in OS X, for instance, or in Windows, save that the Windows version of OpenGL is quite a bit newer than what Apple is still using inside OS X.

      Anyway, the test for Vulkan will come from game devs. OpenGL before it was also “cross-platform” in exactly the same way that Vulkan is, so that aspect is hardly new. Yet, D3d clobbered it consistently through the years even though D3d was not cross-platform, because the Microsoft-supplied developer tools for D3d management were second to none (no contest, really.) Khronos group will have its work cut out and I for one hope they’ll do a much better job with Vulkan than the infamous “ARB Committee” managed with OpenGL down through the years. They’ll have to if Vulkan is to gain any traction at all.

      • Geebs says:

        I dunno, from current performance reports it’s not so much “better” as “different”. There were already plenty of ways to minimise draw calls and thread blocking in OpenGL 4, while the PCIe bottleneck between GPU and CPU is as tight as it ever was.

        Vulkan and DX12 are going to be great for the big names in game engines; not so much for the independent coder, because they can no longer rely on the hardware vendor optimising the drivers for the higher-level stuff.

        • DFX2KX says:

          I suspect that a lot of the bigger engines will provide some level of base functionality for indie devs, you might not get quite the performance boost out of it, but at least it’ll run.

    • Cinek says:

      I never liked M$” – lol. WTF it this? ’90s?

  7. AceJohnny says:

    > The only obvious omission at this stage is Apple, which is going it alone as ever with its Metal API.

    And this is really the big problem.

    Apple has huge control over the mobile gaming sector, as that’s where the majority of mobile gaming profits are (what there is to get). However on desktops, their OpenGL performance is poor, at best. Obviously they focused their engineering efforts on Metal.

    How long is that going to last? Are they going to adopt Vulkan somewhere down the line? It sounds like their policy is “Game developers shouldn’t care, it’s a middleware issue”, and since Unreal Engine and Unity support both, they can pretend that’s good enough. Except, of course, it isn’t.

    As a macbook owner, I am sad.

    • mattevansc3 says:

      They can focus on Metal because they design and build their own ARM chips, whereas the Mac’s utilise AMD, Intel and NVidia gpus.

    • Nouser says:

      The situation is kinda different between Apple’s PCs and their mobile devices.

      Macs and Macbooks are still a kinda open platform. You can develop using essentially any framework for it, and it’s on Apple best interest to give proper support to industry standards so their own platform doesn’t get handicapped when it comes to 3rd party’s tools support. However, I suspect only newest models will receive Vulkan support even if the older models are Vulkan-capable due to Apple’ custom drivers policy (which is the reason they are severely lagging behind in OpenGL support).

      On the other hand, iPhones and iPad will likely only support Metal, because Apple knows it has the upper hand in the mobile space and tries to close its platform as much as possible. So their devices will likely go with their own graphic API solution instead of relying on a multi-platform solution which would facilitate portability.

      • Geebs says:

        The OpenGL driver situation on Windows isn’t much less strange than Apple’s we’ll-do-it-ourselves thing. On Windows, the entire OpenGL stack comes from the IHV as part of the “driver” – so if you compile your game on an Nvidia system, you will get a different result from an AMD system.

        • Nouser says:

          That situation is the same in almost every OpenGL-capable system, the vendor is responsible for providing its own OGL shared libraries, since Khronos only provides headers and specifications. The exception are the drivers under the Mesa project, which share the same high-level OGL implementation and only the platform-specific bits are different.

    • The Sombrero Kid says:

      Don’t worry about Apple, they aren’t providing a driver because they don’t feel the need, but they also can’t stop someone else providing a vulkan compliant metal wrapper. It won’t be anything like wine or cider, the drivers are much thinner and API’s very similar so wrapping them will have very little overhead.

      Also Apple aren’t providing a driver right now but if vulkan is a success they will have to. The API won’t be made or broken on iOS, you can count the number of developers who wrote a metal renderer on one hand and those people are already writing their vulkan renderers because it’s trivial to port between these new API’s.

  8. Don Reba says:

    “One API to rule them all.” Bill Gates

    • Cinek says:

      First of all – it’s Steve, not Bill. And secondly – DX still “rules them all” regardless if OpenGL and now Vulkan fans want it or not.

      • DFX2KX says:

        by the size of market share, yes. That being said, an alternative that lets me make games for all of those people who don’t want Windows 10, while still getting solid performance (IE, not OpenGL) is a good thing.

  9. Jay Load says:

    Ooooh, fascinating. Someone mentioned Vulkan here about a week ago and I went and had a wee look at it. I really want there to be an end to Microsoft’s dominance of the GFX API sector, for all the reasons mentioned and more. I really want Linux to benefit from a robust API that developers want to code for, again because I’m sick of MS dominance when they treat PC gamers so very poorly. I’m about to switch from an AMD card to an NVIDIA jobbie, with Linux gaming in mind, so I’m really interested to see how this pans out. I love that so many are already on board with it. Poor old OpenGL just never had a chance.

    • anevilyak says:

      Bear in mind, both OpenGL and previous iterations of DirectX’s overall design were based on very, very old GPU designs with fixed function rendering pipelines. Modern day GPUs are completely different beasts, and both APIs were pretty much being strained to the breaking point when trying to work with them, hence the increasingly poor performance. Both sides really did need the ground up redesign that DX12 and Vulkan have brought to the table because they were simply no longer suited to the modern day world of GPU design, though that was even moreso the case for OpenGL since it’s mostly been kept up-to-date via an increasing number of vendor-specific extensions without really changing the core design.

    • Gibs says:

      MS dominance of the gfx api? ahah no, just never happened

  10. stalker says:

    Vulkan itself isn’t open ‘source’!

    The API spec is ‘open’ and Intel are releasing an open source driver (the intel specific implementation of the Vulkan API). But none of the others are required to do so.

    • baltasaronmeth says:

      As far as I know, AMD tries to provide an official “mostly OSS” driver right now (amdgpu), which is good, because their closed driver is a mess and the open driver could need a little tweaking here and there.

      The NVIDIA situation is entirely different. The closed blob works well (more or less, most of the time) and resistance from the userbase is not harsh enough to make them reconsider. I read, that the most recent blob has Wayland and Mir support (full KMS support?). I don’t expect an offcial open NVIDIA driver any time soon.

  11. steves says:

    Good article.

    Isn’t the second image the GL ‘train’ though? It has Apple in there.

    And what did Nintendo do to get circled in red?

    • Jeremy Laird says:

      Yeah, probably. Seems I got on the wrong train. Doh!

    • Gabbo says:

      Wasn’t Apple initially involved before they decided to go full bore with Metal, hence their name appearing in the image? I believe that was the case.

      Why it has Nintendo circled, I suppose it depends on where it was sourced. Probably someone used it to point out Nintendo’s involvement on some level

  12. mattevansc3 says:

    Normally the tech articles from you are really good but this one seems a bit to “high level”, pardon the pun.

    Apart from the last few paragraphs it lacks that critical eye that make your articles a real good read.

    DirectX is used to refer to DX11 and earlier even though DX12 is part of the DX12 family and corrects previous issues.

    The benefits of Vulkan are discussed as if DX12 doesn’t exist. You’ve listed a load of engines and developers as “pro-Vulkan” even though all of them bar Valve have already built in or confirmed they will build in DX12 support.

    While Vulkan started out as Mantle the guy running Khronos is an NVidia higher up which means NVidia will always have a controlling hand in Vulkan development.

    Yes Khronos has a huge list of supporters but they are split into tiers with the majority agreeing to supporting a royalty free patent pool and have zero involvement in the development of Vulkan. The likes of Microsoft, Sony and Nintendo don’t have to use Vulkan but can still utilise elements of it in their own APIs.

    This piece seems more about promoting Vulkan than actually analysing it.

    • Jeremy Laird says:

      Well, there’s not much to be critical about and while I did read broadly to get a feel for the technical details, truly meaningful analysis of the API is a very, very tall order.

      I linked to previous content outlining the promises of DX12 both in the TL;DR and later in the piece. I’ve outlined that Vulkan is pitched as offering many of the same benefits.

      If I could have said Vulkan is clearly going to be better or worse than DX12 for gaming, I would have. But can anyone really say that right now? I doubt it.

      My ambitions here are fairly modest and introductory. Hopefully RPSers who have read this will have a reasonable idea what Vulkan is when it’s mentioned and not wonder, oh, what’s that, will I be able to use it / will it run on my PC, what’s all this, then. Basically I think it’s too early for meaningful analysis, so I didn’t attempt it. But the Vulkan chatter is increasing, so it’s worth just saying there’s this new thing coming and it might be interesting.

      The ‘pro-Vulkan bit’ I admit is ripe for misinterpretation, but I did not mean to imply they were pro Vulkan at the expense of anything else.

      Hope that provides a little context.

      • xyzzy frobozz says:

        I think you hit your own brief pretty well.

      • mattevansc3 says:

        Sorry Jeremy, it was a bit jarring reading such a “positive” article from you.

        Even though RPS isn’t a tech orientated site I rate your work as highly as that of the better tech sites like Anandtech or Arstechnica and I look forward to your comparison between DX12 and Vulkan.

        • Jeremy Laird says:

          Kind words, thanks.

          I usually take the opportunity to be cynical about unproven tech, but it’s just a little too early to grumble about Vulkan, I feel!

          If nothing else, if it’s half decent it will keep MS/DX on its toes, so we’ll all benefit from it without necessarily using it much.

  13. LionsPhil says:

    I’m not sure I’ve ever seen a more punchable robot.

  14. syllopsium says:

    One nitpick : Vulkan isn’t a successor to OpenGL. It would be possible to implement OpenGL on top of Vulkan.

    OpenGL isn’t going to die off any time soon due to the amount of historical software, especially CAD/Visualisation.

    • Jeremy Laird says:

      Vulkan is the successor to OpenGL. That doesn’t mean OpenGL disappears. But Vulkan is its successor.

      • Gibs says:

        it’s just the name of the new version of ogl afaik?

        • Nouser says:

          It was supposed to be OpenGL 5.0 but the required API changes were so massive it’s no longer compatible with classic OGL, so the idea now is keeping both Vulkan and OpenGL as the “low-level” and the “high-level” graphic APIs.

  15. Fitzmogwai says:

    Fingers crossed it all works out. I wouldn’t touch Windows 10 with yours and because my work software doesn’t come in linux flavour an OS switch isn’t a possibility. So if this means I can get all the new shiny and stay with Windows 7 then I’m all for it.

  16. Avus says:

    I really hope Vulkan API will get popular because gaming (or DirectX) is the ONLY reason why I “have to” stay with MS Windows. I don’t even use MS Office anymore. (Google doc is good enough for my own business and I mostly use PDF to deal with others/clients) I never use Internet Explorer (used Netscape, then Firefox and Chrome) Most of my PC games are in Steam (thanks for MS doing almost NOTHING for PC gaming since their Xbox division started in 2001. And I (rarely) buy music using iTunes (thanks again MS for doing NOTHING for their own platform in 2001. Last I use Android for mobile devices (my first mobile phone was a Windows Mobile 2003 thanks MS for their lack of innovation on that POS platform)

    I really hope SteamOS will get popular and success – an OS that made for PC gaming, much less overhead that MS OSes and no need to deal with Windows registry.

  17. dsch says:

    Am mildly displeased that Khronos is using a Greek name for the group but a (pseudo-)Latin one for the API.

  18. Xzi says:

    Vulkan can be installed on machines that have DirectX 12, correct? Works on both AMD and Nvidia cards, after all. So it seems like there’s really no reason developers shouldn’t transition over, be it quickly or slowly.


      Vulkan can be used on many different machines. DX12 is just for windows 10 on pc.

      • Xzi says:

        Yeah, should have phrased as, “Vulkan can exist alongside DirectX on the same machine.”

    • Cinek says:

      Yes, it is correct. As for transition – from DX11/OpenGL to Vulcan/DX12 – sure. In any other direction – nope.

  19. narcogen says:

    Apple is making another QuickDraw3D mistake.

    • deadlybydsgn says:

      Will it coincide with the release of the Apple Pippin 360?

  20. DanMan says:

    That must have been very boring 5h, if that was all you got out of them, because you ought to have know most of this already – if not all. But thanks for doing an article about it anyway.

  21. BarneyL says:

    “It’ll run on AMD graphics cards right back to Radeon HD 7000 series and Nvidia GeForce 600 series boards and newer”

    So completely unusable for me at present and a quick check at the Steam hardware survey suggests this will be true for the majority of users. I guess we’ll all just ignore this and continue using DirectX.
    How is this supposed to get widespread support if no one can use it?

    • TormDK says:

      Plenty of people can use it though, so “No one can use it!” comment is a bit too wide.

      And if you are stuck on something that predates the Geforce 600 series, then you really should be upgrading by now, or at the very latest this summer when Pascal GPU’s hit the market.

  22. Mark Ackerman says:

    I would love to test this with the publicbeta But installing the Nvidia driver via the downloaded .run file (with Vulkan)always 50/50 times will result in a black screen on reboot no matter how you install it (I am talking about Linux of course) and I have tried every method in the last 8 years in Linux trying bleeding edge NVidia drivers.

    Please add a PPA so I can use “Driver Manager – Ubuntu-Gnome” to install NVIDIA-Linux-x86_64-364.16

    And I am sure you will get thousands of more people instantly using that driver – Me for ONE.

    We all want to help you,

    Please and Thanks