Does anyone have tried NVIDIA 270.61-notebook-win7-winvista-32bit-international-whql drivers on pre-Fermi based notebook?
270.61 works fine on a desktop with GTX470 and Win7 64-bit, but I had to uninstall it from my laptop. There are plenty of reasons. Driver don’t retrieve any information about itself, no performance states, no sensors reading,… 8600M GT runs under 270.61 in something similar to perf. state 10. The speed is halved, which prevents overheating, but it never drops to perf. state 12. Whatever application you start the speed is the same (medium, i.e. halved). PhysX was not detected also. Now I’m back to 266.58 and everything works perfectly.
Also, be aware of automatic update. It is a new component in 270 drivers, which I have disabled at first place. (I tried to update driver manually trying to fix errors, but currently there is no update available.)
If anyone has similar problems, please respond to this message in order to make NVIDIA aware of the problem. I had tried some unofficial drivers before, so maybe on my system there are some components not replaced with 270.61 which could cause the problem. But, on the other hand, now with 266.58 everything works perfectly.
I haven’t run that specific driver (I don’t do anything in Windows at work), but…
…I tried the analog to that Windows driver version in Linux (270.41.06) last week and had big problems. The app I was running was double-buffered, but it was rendering the “back” buffer on-screen (I saw the preloaded textures prerender), and some other strange behavior.
I haven’t had time to mess with it lately so I’ve dropped down to the prior version (260.19.44) for now. May get back to it after crunch time… This hardly ever happens with NVidia drivers, so I want to make sure it’s not something in the app.
Would be interested in hearing about anyone else’s issues with Win 270.61 or Linux 270.41.06.
Retrying with this driver (first 270 series driver on Linux: 270.41.06), this app just core dumps on startup setting up an FBO attachment. Revert to 260.19.44 or lower, and no problems. GTX480 GPU.
They claim that are not aware of the problem, but last night I sent them a detailed and illustrated report about the errors on Windows.
I hope they’ll fix it up soon. In the meantime, stick to the previous release.
By the way, the brand new drivers are released - GeForce Driver v275.27. But they are in the beta phase yet. NV claims that it is the beginning of the new series of drivers (versions 275.xx to 279.xx).
What’s new?
Well, two new extensions for us (GL developers):
GL_NV_path_rendering
WGL_NV_DX_interop2
Other improvements are related to games, mostly. They claim performance is boosted for dozen of games. (I thought games have to be optimized for the drivers, but as I we can see, new tendency in the development is to adjust drivers to games needs ).
NV update is also updated. It is a new feature first introduced in 270.xx series of drivers, and one I dislike mostly. As an advanced user, I don’t want anything to be updated automatically. Maybe it works fine, but so far that update doesn’t work, because I update drivers more frequently than patches release.
All of the newer drivers (270+) I’ve tested locally appear to have rather broken OpenGL implementations - so just confirming for you!
I think the biggest issue I’ve encountered are OpenGL contexts now being thread-local (Create GL context in Thread A, terminate Thread A - GL context is destroyed with the thread).
But there are numerous issues to do with ‘unmaking’ the current context as well.
Retrying with some more recent drivers, and on an older GPU, looks like it’s still an issue even with the latest 275.09 beta drivers.
Common symptom, whether on GTX285 or GTX480, regardless of driver version >= 270.x, is a crash deep in the driver when making a glFramebufferTexture2D() or glFramebufferTextureLayer() to set up a FBO on startup. Disable all “FBO-using code” in the app, and it seems to work fine.
Next week when I get some time I’ll have to isolate out a test case to repro the problem. May be something I’m doing – it’s just odd that everything works perfectly up through 260.19.44.
On my desktop i7/GTX470/Win7 64-bit I haven’t had OpenGL related problems (although I haven’t tested thoroughly, and there were several driver restarts during simultaneous playbacks in web browser), but on my laptop 27x.xx drivers simply don’t work correctly. I won’t repeat what I said before, but the greatest problem is that driver doesn’t report its state. There are no performance states at all.
Yesterday I returned the state of the laptop to factory default. The partition is formatted and I performed a clean installation of Windows Vista 32-bit (the licensed version came with the laptop). After initial update, two service packs and post-update of Windows and drivers, 275.33 NV driver was installed. The behavior was quite the same. No performance states! So I had to return to 266.58.
Final conclusion: NV 27x.xx drivers don’t work correctly on GX600 laptop with 8600M GT and Windows Vista 32-bit SP2.
The loss of seeing state jazz and the under clocking sound not so nice, but do you have code like Phantom that just dies in the newer drivers? I am wondering if there is some setting in the driver/laptop where the GPU stays under clocked if the laptop is not plugged in (I have a Dell Studio and the ATI GPU is at half performance when it is not plugged in) but that theory od not being plugged in sounds fishy since you don’t have the issue with older drivers.
By the way, what do you use to get the state jazz under Windows?
For reference, the FBO code I have is using glFramebufferTexture (not glFramebufferTexture2D or glFramebufferTextureLayer), I just would like to know what parts of the GL implementation in it are hosed or cause crashes…
I am curios to give this a whirl, I’ve got 2 laptops with NVDIA GPU’s one has a 8700M and the other is a 360M, I have not seen issues in Linux, but I’ll give it a whirl and see what happens under Windows ( one is 32-bit Vista the other is Windows 7 64bit) with those (the desktop for me, like you, seems happy, GPU Caps Viewer gives temperatures, etc).
I changed my mind on weather or not to post it to the forum
At any rate I tested 275.33 on 2 different laptops:
Laptop 1:
Vista 32-bit
GeForce 8700M GT
(model is Toshiba Satellite X205-S7483)
Laptop 2:
Windows 7 64-bit
GeForce 360M
(model is ASUS G60JX-RBBX0)
for both of these, GPUShark (v0.50) got temperatures, memory usage, and clock frequencies. Additionally, a biggish GL3 application ran (more or less) the same with 275.33 as with previous versions. The gauges from GPUShare indicated elevated temperatures, increase in clock speeds and change to “State 0” when the application was running and when the box was idle the clock speeds wen down, temperature some and the state to “State 12”.
At first I was thinking there must be something in the context creation beans (I have a colleague that has had to make an application which has many “offscreen GL contexts” where NVIDIA gave issues under MS-Windows but any other combination of hardware and OS was fine), but that does not answer the issue of the GPU clock being low always… maybe there is an epic-odd interaction between the video BIOS on your laptop and the newer drivers?
On Linux, it’s the same here with one of our big applications and 270.x. Don’t do anything with FBO’s and all’s fine. Use FBO’s and you’re dead, literally.
On Linux, it’s the same here with one of our big applications and 270.x. Don’t do anything with FBO’s and all’s fine. Use FBO’s and you’re dead, literally.
The issue my colleague had was with older drivers (and I guess current ones too), but it was multi-context “fun”, i.e. not FBO’s but basically render to pixmaps.
Thing that makes me paranoid is that I have a large GL application that does use FBO’s but I have not experienced any crashes with the new drivers (in Linux or MS-Windows)… the FBO code uses glFramebufferTexture (not glFramebufferTexture2D or glFramebufferTextureLayer)… the application is such that if the FBO jazz fails not only will it spam to stderr and nothing at all would be displayed… but it works just fine…
