Nvidia GeForce GTX 900 Series MegaThread: FAQ and Resources

Page 14 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar


But that doesn't make any bloody sense.

I have all the Game Experience crap disabled because it's a resource hog POG. What the hell is wrong with nVidia?

Cheers!

EDIT: Ok, just read it fully. It won't be exclusively, but primarily. They will still do the regular web page drivers, but less frequently.
 
@Eggz That's a terrible idea. I remember when I unchecked some of the updates (hd audio, physx) thinking I was supposed to do that because there were no new versions, and ended up uninstalling them. When I tried to update after that it would tell me there are no new updates because it only looks at your graphics driver version. If they're gonna remove direct driver downloads they better fix the geforce experience.
 


Ha, don't kill the messenger. I have no agency at Nvidia whatsoever. Just relaying what they announced to the public.

Reports are inconsistent, but if you get any website updates at all next year, it will probably be only four times per year at most. Given that, I wouldn't be surprised to see them phase out direct downloads entirely. And that would, of course, spur greater attention to the workability of Geforce Experience.

One of my personal issues with obtaining drivers through Geforce Experience at the moment is that you can't save them anywhere. It works like "Run" used to in Internet Explorer. Once the driver executable runs, the temp file disappears. That usually not a big deal, but it makes reinstalling annoying on a slow internet connection - and impossible offline.
 


Does it not unpack them to the Nvidia folder in Windows then?
 

When you do the full uninstall/install routine, it cleans out anything Nvidia related, including the root C/Nvidia folder. It then reboots automatically into safe mode and then allows you to install your drivers. I suppose, at the point of reboot I would open GFE and have it do a clean install of the latest. That is, if GFE isn't uninstalled during the cleaning process, at which point I assume I would install the full downloaded drivers, then use GFE to update to the most recent Game Ready ones. If that's how it would work, seems like a bit of a hassle.

I still have my hopes that Nvidia will change its mind after reading some of the forum comments/rage.
 
For me i just don't like the fact they kill other source to download the driver unless you willing to wait for 3 months until they release them. Personally i don't mind about having the latest driver. And like it or not at one point we might have to use DDU. For me the biggest concern would ne redownloading the drivers since my home internet is only 1Mbps.
 


When I've run DDU it hasn't touched the root folders. Some testing may be required methinks.
 
Just to answer a couple points that came up about DDU and this driver roll out scheme:

What DDU touches: DDU deletes Nvidia stuff in "Program Files," "Program Fils (x86)," and the registry keys. Certain versions of it will uninstall the "C:\Nvidia" folder only if you check the box for that, but the box disappeared at some point, so it may be a default thing in newer versions.

A workaround I found for everyone to use: As for whether Geforce Experience unpacks drivers into the C:\Nvidia folder, it's actually not there. I did some testing, and the driver package gets burried in some strange place under "C:\ProgramData," which is hidden by default (i.e. you'll have to change your folder options to see it). This does, however, permit a workaround.

(1) Go through the download within Geforce Experience

(2) Finish the download but not the installation.

(3) Navigate to "C:\ProgramData\NVIDIA Corporation\NetService\"

(4) Find the strangely-named subfolder for the new driver package. There were several, but the subfolder for driver 358.50 were under "d3b6068c-6c9a-45a5-a3f9-0e151368062f" Just be sure the file you copy is roughly between 200 and 300 MB. There are files in other subfolders that are clearly too small to be a driver package.

(5) Copy the driver package executable to a location DDU won't touch or use (e.g. desktop).

(6) Run DDU in safemode

(7) Run the driver package from wherever you saved it, if not the desktop


Going through the steps to test just now, it actually takes similar or less time than downloading from the website once you know where the file gets saved. Instead of running the driver package from your browser's download folder, you just run it from Geforce Experience's download folder.

Yes, it's different. But me telling you here that Geforce Experience's download folder was in "C:\ProgramData\NVIDIA Corporation\NetService\d3b6068c-6c9a-45a5-a3f9-0e151368062f" should make things simple during the time it will take Nvidia to smooth out the process for people

🙂
 
Still it needs game developer actually to implement it. Which made me thinking if nvidia and AMD going to release new gpu in the future will game developer going to patch their older games to work with newer hardware? In the past it is not an issue because the profiles are provided by gpu maker themselves. So even if the said game studio no longer exist SLI /CF csn still work on newer hardware.
 

i don't think DirectX 12 Explicit Multi-Adapter needs patch for new hardwares. if it needs coding on the basis of every different hardware, whole point of low level api features goes down the drain. After all this new api was meant to make things better.
 
Isn't that what low level is? You tune the code down to architecture specific so you can take out the hardware potential to it's fullest. If the code can work on various hardware then that is still not consired as low level.
 
Low level api isn't tuning code to be architecture specific but writing software that drives the hardware directly without going through a software translation layer and its associated overhead.
By the way, I've improved my previous comment.
 
But the very purpose of going low level is so you can maximize your performance. One generic code will not going to do that. Probably why with current DX12 nvidia performance could be worse instead of improving. Because developer like Oxide probably assume that nvidia Async compute work the same like AMD Async compute when it fact on hardware level nvidia handle those stuff differently. Since nvidia did not handle it the same way Oxide might need to make specific optimization that meant for nvidia hardware only. It is the same with OpenCL. You either choose portability or optimization. But you can't have both at the same time. You want to maximize your performance? Then you tune down your code to that specific architecture.
 
There will definitely be differences in how different game engines utilize dx12. Some will favour nvidia, some amd. That doesn't mean DirectX 12 Explicit Multi-Adapter will need patches with every new hardware coming to market. The software now will interact with hardware at a close level but it won't be vendor specific commands. Oxide games said the the only vendor specific command they used was to disable async compute in nvidia hardware. Though it might have already changed or will change with the coming of Pascal.
 
So far only Oxide use multi adapter multi gpu. We will have to see if patch are needed for new hardware or not when they put support more than just high end card. Thogh i believe if there really no need for patch for different hardware then anandtech should be able to test mid range and low end card already by now even if the performance still having issues.

That aside they need to address the performance deficit in maxwell. If nvidia async compute did not work the same way as AMD ones then they probably have to use few tricks that only specific to nvidia cards to pull out more performance. Because if they can't pull better performance in DX12 than nvidia DX11 performance then it defeat the purpose of using DX12 to begin with. At least for nvidia hardware.
 
Anandtech has used 2 cards from 2012. They are 680 and 7970. I think I've read somewhere that Oxide used integrated graphics with 290 in their demo.
For the moment nvidia has already advised game makers to use async compute only when there is real benefit in using it. It is present in nvidia's guidance for dx12. Seems to me nvidia wants them to go slow with it until pascal comes and brings full hardware support for dx12 .
 
Honestly i'm not sure. Actuallly there is a lot of debate right now even among DX developer. But general concesus is AMD Async compute probably only exclusive to AMD hardware right now. amd define Async compute as doing graphic and compute simultaneously. But some DX developer said that even in DirectX 12 guide you did not do both at the same time as AMD try to describe it. You still only do graphic after compute is done. Not do both at the same time. In fact Oxide developer once mention that they probably understand the spec the wrong way. For AMD part Async compute is preety much something they push since the very beginning of GCN. But only with DX12 and Mantle they have the capability of using their ACE.
 
Vulkan also has capability of using parallel compute but probably you meant it so by writing Mantle.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom