Announcement

Collapse
No announcement yet.

NVIDIA Releases 285.03 Beta Linux Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NVIDIA Releases 285.03 Beta Linux Driver

    Phoronix: NVIDIA Releases 285.03 Beta Linux Driver

    While some NVIDIA Linux developers are up here in Vancouver for LinuxCon (met some friendly and informative NVIDIA engineers at the Linux Foundation gala last night), the NVIDIA Linux desktop team back in Santa Clara has put out the first 285.xx Linux driver series beta now that the 280 driver was made official earlier in the month...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    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.
    Elaborated clock-tree? That's the least they can say! This thing is really becoming crazy. Just have a look at this https://github.com/pathscale/envytoo...cs/nvclock.txt

    Anyway, I don't understand why they moved the code outside of the driver. I guess their problem is that there are many places where you can alter the clock of a single engine and they usually also affects some other engines too.
    We are hard at work with getting Fermi reclocking available. Maybe we can provide an interface for overclocking too when reclocking is merged upstream.

    Comment


    • #3
      Optimus...

      And what about Optimus... Will they implement it on next version? There are any advance on that matter?

      Comment


      • #4
        Originally posted by So7t View Post
        And what about Optimus... Will they implement it on next version? There are any advance on that matter?
        Ask they, and sometime they maybe implement it.

        Comment


        • #5
          The lack of Optimus is an architectural issue, not a driver one. Look into Bumblebee and see how that works to get an idea of why it's not just a case of nVidia supporting it. The entire OS as a whole needs to work together.

          Comment


          • #6
            Originally posted by Enverex View Post
            The lack of Optimus is an architectural issue, not a driver one. Look into Bumblebee and see how that works to get an idea of why it's not just a case of nVidia supporting it. The entire OS as a whole needs to work together.
            I don?t see the problem here.
            Linux has drivers and has udev.
            The Xorg drivers are present and separate from core xserver. They work fine with kernel modules too.

            The idea to copy the frame buffer from one device into another, change their power states and switch contexts shouldn?t be problematic.
            Its just that linux doesn?t get sold to 99% of people and as such the company pioneering this technology can not profit so much from implementing it and puting it on the box.

            Linux needs to become monopoly, don?t you see.

            Comment

            Working...
            X