21–30 of 77 posts
I cant prove this but my computer blue screened after a Nvidia driver update. It took my several hours to get everything working again because it wouldnt even launch in safe mode. Very frustrating. I wish they had a little more quality control on their drivers.
Oh trust me, they do tons of QA. If you can replicate what problem you have demonstrably with steps that QA can follow and you submit to the Nvforums or whatever, someone in the QA team will eventually try it out.
Earlier quoted context omitted.
Oh trust me, they do tons of QA. If you can replicate what problem you have demonstrably with steps that QA can follow and you submit to the Nvforums or whatever, someone in the QA team will eventually try it out.
I once interviewed for a Software Engineering role with an Nvidia QA team in Austin 5 or 6 years ago(would have been working on maintaining the test software that validated new drivers on huge banks of test hardware, if memory serves). Wasn't too terribly impressed with the team (and a couple of them were definitely giving off that "I hate my job/life" vibe, one disgruntled fellow was even trying to drop little thinl…
I cant prove this but my computer blue screened after a Nvidia driver update. It took my several hours to get everything working again because it wouldnt even launch in safe mode. Very frustrating. I wish they had a little more quality control on their drivers.
You're being down voted but I had the exact same behavior last week, in the end I gave up trying to fix it and reinstalled Windows to a new drive, at some point I'll wipe my old 'C' and move my new 'C' back to the fastest boot drive.
You can try to remove all the NV kernelmode driver files manually, at which point it should just fallback on the default VGA driver. Then you can use the DDU[1] tool to cleanup any remaining files, and do a clean install with a driver from nvidia.com.
Do you perhaps remember what the bugcheck code was, and which driver was listed as the offender? If you have a kernel minidump still available, that'd be helpful as well.
[1]: http://www.guru3d.com/files-details/display-driver-uninstall...
Earlier quoted context omitted.
Yeah - that sounds like fun - recreating a driver install issue after you finally have it working on your system. Heck, even if you set up a system -just- to recreate this problem, it would still be one of those "nightmare inducing" trials of will. I'm not saying it shouldn't be done, I just can't imagine doing it (especially on my personal workstation).
Plus you paid for the computer, graphic card and OS. Why in hell would you spend hours of work on your free time for this ? Do people try to find defects in their car then send a report to Ferrari ?
I cant prove this but my computer blue screened after a Nvidia driver update. It took my several hours to get everything working again because it wouldnt even launch in safe mode. Very frustrating. I wish they had a little more quality control on their drivers.
They make cards w/ 4x DisplayPort connectors, but apparently multiple monitors isn't part of their quality assurance process? That seems a mite silly to me.
A lot of people hated the decision, but back when Microsoft refused to support WebGL, one of the reasons were that the GPU drivers were awful and exposing them to the internet was dangerous. The proper solution, of course, i for GPU drivers not to suck but it was still a legitimate point and this article seems to validate that.
They were right that it was dangerous, but it became pretty clear that IE was using them to provide cover for not implementing a feature when they changed their mind later. Whereas Chrome implemented a WebGL compiler that reduced the amount of attack surface WebGL could reach and audited a bunch of popular drivers to fix the exposed bits. I think the fact that this blog shows that these vulnerabilities are not reacha…
GPUs are both really complex and highly secretive about their implementations. The incentive for GPU vendors is to write fast drivers. Security is pretty far down on the list, esp when it competes directly against performance.
A lot of people hated the decision, but back when Microsoft refused to support WebGL, one of the reasons were that the GPU drivers were awful and exposing them to the internet was dangerous. The proper solution, of course, i for GPU drivers not to suck but it was still a legitimate point and this article seems to validate that.
A lot of people hated the decision, but back when Microsoft refused to support WebGL, one of the reasons were that the GPU drivers were awful and exposing them to the internet was dangerous. The proper solution, of course, i for GPU drivers not to suck but it was still a legitimate point and this article seems to validate that.
MS's security side may have been against WebGL and the IE team either agreeing or using it as an excuse (and really, from this point of view, it doesn't matter!), but other parts of the company were exposing the web to the exact same problems.
Getting these issues fixed in the drivers is great, no doubt. But it's moot if nobody actually updates to those fixed versions. How hard are nVidia/Microsoft trying to actually push these out over Windows Update so that end users will actually benefit from all of this work?
I want to say Microsoft will push them out a little later, but I can't be entirely sure since I've always used the nVidia path.
EDIT: Unfortunately the GeForce Experience is getting, as is typical, super invasive. Access to even basic settings requires an account (nVidia or Facebook account, etc).
Earlier quoted context omitted.
They were right that it was dangerous, but it became pretty clear that IE was using them to provide cover for not implementing a feature when they changed their mind later. Whereas Chrome implemented a WebGL compiler that reduced the amount of attack surface WebGL could reach and audited a bunch of popular drivers to fix the exposed bits. I think the fact that this blog shows that these vulnerabilities are not reacha…
I think there's probably still a fair bit of attack surface behind glReadPixels() and the like. All it takes in a single backbuffer/texture/surface/etc to not be memzero'd properly and you can start looking at parts of the system's memory. GPUs are both really complex and highly secretive about their implementations. The incentive for GPU vendors is to write fast drivers. Security is pretty far down on the list, esp…
>...you can start looking at parts of the system's memory
I thought the whole point of using glReadPixels(), as opposed to just dereferencing a pointer in the system's address space, was that the framebuffer memory it accesses (whether backed by a texture or a surface or whatever) is GPU memory, and not system memory?