Release highlights:
Not mentioned:
32-bit / 64-bit on the site
also see the README
not yet on FTP
is it just me or the drivers got bigger and bigger since 27x.xx ?
also, zander from nVidia on Fermi overclocking:
- Fixed a bug causing corruption of images which are 2047 pixels wide.
- Improved performance of the RENDER extension on Fermi-based GPUs.
- Fixed a bug causing the X server to crash after a VT-switch while running an OpenGL stereo application which is a member of a swap group.
Not mentioned:
- OpenGL Version: 4.2.0 NVIDIA 285.03
32-bit / 64-bit on the site
also see the README
not yet on FTP
is it just me or the drivers got bigger and bigger since 27x.xx ?
also, zander from nVidia on Fermi overclocking:
It wasn't so much a policy decision, it was more a question of picking battles.
FERMI GPUs are very complex, with elaborate clock trees and memory interfaces (e.g. GDDR5, EDC, ECC, etc.). The NV-CONTROL overclocking interface, on the other hand, is quite naive. In order to properly support clock manipulation on FERMI and newer GPUs, a fair amount of work will need to be done in at least the X driver, NV-CONTROL and nvidia-settings to overhaul the overclocking infrastructure. I believe on Windows, a lot of this type of functionality was moved outside of the driver for that reason.
We do have a bug tracking this RFE internally, and I expect we'll get to it eventually. But given ever-increasing hardware/software complexity, general driver quality concerns and other long-standing feature requests (such as the long-neglected RandR extension), it's hard to justify the effort for a small subset of the NVIDIA Linux graphics driver user base at this time.
FERMI GPUs are very complex, with elaborate clock trees and memory interfaces (e.g. GDDR5, EDC, ECC, etc.). The NV-CONTROL overclocking interface, on the other hand, is quite naive. In order to properly support clock manipulation on FERMI and newer GPUs, a fair amount of work will need to be done in at least the X driver, NV-CONTROL and nvidia-settings to overhaul the overclocking infrastructure. I believe on Windows, a lot of this type of functionality was moved outside of the driver for that reason.
We do have a bug tracking this RFE internally, and I expect we'll get to it eventually. But given ever-increasing hardware/software complexity, general driver quality concerns and other long-standing feature requests (such as the long-neglected RandR extension), it's hard to justify the effort for a small subset of the NVIDIA Linux graphics driver user base at this time.