Announcement

Collapse
No announcement yet.

NV50 Global Performance Counters For Nouveau

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

  • NV50 Global Performance Counters For Nouveau

    Phoronix: NV50 Global Performance Counters For Nouveau

    Samuel Pitoiset has continued reverse-engineering NVIDIA's hardware performance counters and implementing them for use under Linux by the open-source Nouveau driver. His latest "RFC" patches are for exposing the NV50 global performance counters...

    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
    I don't really know exactly what is the purpouse of this feature. For me it sounds like a pure stadistical feature for programmers.

    From the user's perspective, I wish to know, how much difficult is to implement the power management on nouveau. When would be ready.

    It would be the real improvement, thought.
    Last edited by DebianLinuxero; 23 June 2015, 04:47 PM.

    Comment


    • #3
      Originally posted by DebianLinuxero View Post
      From the user's perspective, I wish to know, how much difficult is to implement the power management on nuveau. When would be ready.

      It would be the real improvement, thought.
      By "power management", I assume you mean the ability to change engine and memory clocks. Very difficult (especially the memory clocks bit of it). I wouldn't expect an actual timeline. My usual guess when people ask is that it'd take 3-9 months of full-time development for a qualified engineer to get reclocking up and running on a reasonable fraction of Fermi chips. Nobody is really up for such a task. I certainly know that Ben has spent lots of time banging his head against GDDR5 reclocking on Kepler with limited success (at least it tends to handle the lower levels, usually).

      Note that it is partially available for Kepler chips already, and some of the later (but overall much older) Tesla chips.

      Comment


      • #4
        Yes, I meant "reclocking".

        I could never think that setting clocks would be so much problematic in comparision of, for example, the video primitives thing.

        But hell, if you say 3 to 9 months then it must be a real pain.

        Thanks for the answer.


        PS : Is there any way a simple user could help in the development? Something like run some test program and feedback the results?

        Comment


        • #5
          Originally posted by DebianLinuxero View Post
          Yes, I meant "reclocking".

          I could never think that setting clocks would be so much problematic in comparision of, for example, the video primitives thing.
          Unfortunately the interface isn't "write clock speed to register". It's "write a lot of board-specific values to a lot of registers, in the proper sequence, interact with the hardware which may provide varying results based on... phase of the moon... and deal with the various outcomes properly". So we need to figure out where the board-specific values are stored and where to write them, and how to deal with the hardware doing various things. The biggie is memory link training but there's loads of little bits.


          PS : Is there any way a simple user could help in the development? Something like run some test program and feedback the results?
          For reclocking? Step 1 is "find motivated developer". Once that developer has gotten all of the locally available hardware to work, testing by others will hopefully help get the remaining kinks out of the system.

          Comment

          Working...
          X