Announcement

Collapse
No announcement yet.

Nouveau Persevered In 2017 For Open-Source NVIDIA But 2018 Could Be Much Better

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

  • Nouveau Persevered In 2017 For Open-Source NVIDIA But 2018 Could Be Much Better

    Phoronix: Nouveau Persevered In 2017 For Open-Source NVIDIA But 2018 Could Be Much Better

    The open-source NVIDIA "Nouveau" driver project providing independent, reverse-engineered 3D graphics driver support for GeForce GPUs made a lot of progress in 2017 although not as great as many would have hoped for. But 2018 will hopefully prove to be more interesting...

    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
    What exactly blocks implementing reclocking? It takes a long time to figure out a working way to do it (tedious reverse engineering)? Or something is missing for it?

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      NVIDIA released the signred firmware images,

      Comment


      • #4
        Originally posted by shmerl View Post
        What exactly blocks implementing reclocking? It takes a long time to figure out a working way to do it (tedious reverse engineering)? Or something is missing for it?
        As far as I can tell, with the talented people working on the driver it could be done quite quickly if it were possible to get the thermal system to co-operate. But you need signed firmware to actually adjust the fan speed, so reclocking essentially can't even be attempted since it'll just fry the chip. So it comes down to NVIDIA refusing to release the firmware, as usual.

        Comment


        • #5
          Originally posted by shmerl View Post
          What exactly blocks implementing reclocking? It takes a long time to figure out a working way to do it (tedious reverse engineering)? Or something is missing for it?
          Reclocking must be done in firmware. NVIDIA now requires signed firmware to access a lot of useful functionality. They will never release the firmware in a nice redistributable manner, so the avenues for implementing it become much harder:

          (a) Figure out a way to extract the firmware from their released drivers (harder than it sounds) and how to operate it to do the things we need
          (b) Find a bug in their firmware to use to load our own code into the secure environment (any such exploit would be patched, but once we have a version of the firmware that's exploitable with signatures, we can just keep loading it instead of whatever's the latest)

          Of course all that gets us is ... firmware which can toggle stuff GPU-side. Then we have to develop the scripts to actually perform the reclocking to pass on to the firmware. This is the hard part -- due to the wide variety of hardware, ram chips, etc there can be a lot of variation in those scripts. A single developer might only have 1% of the boards out there, but by fuzzing the vbios and seeing how the blob driver reacts, we can get much more significant coverage.

          As part of the signed-everything logic, the blob driver now also verifies that the VBIOS hasn't been tampered with, which means that developing reclocking scripts will require different techniques.

          Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.

          Comment


          • #6
            Originally posted by imirkin View Post
            Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.
            Pretty much.

            It seems NVIDIA lets Noveau live as a "fallback" driver or "driver to use just during installation phase", they only release enough firmwares to operate the display and provide low-power 3D acceleration.

            Comment


            • #7
              Originally posted by imirkin View Post
              (a) Figure out a way to extract the firmware from their released drivers (harder than it sounds)
              As a matter of interest, how come this is so hard?

              Comment


              • #8
                Originally posted by imirkin View Post
                Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.
                Thanks for explaining the difficulties. Yeah, that's exactly what I did and I'm using AMD for a while now. Just was wondering what practical blockers are there for fully functional open Nvidia driver.

                Comment


                • #9
                  Originally posted by PluMGMK View Post
                  As a matter of interest, how come this is so hard?
                  Well, it used to be that the firmware would just be written into vram by the host cpu. So we captured all that with mmiotrace, and the trace would contain the firmware. We could also go the extra step and then find that firmware embedded in the released binary, and provide a short script to extract it to allow end users to not have to worry about doing the mmiotrace, which is beyond most end users' capabilities. (It sure helped that a bunch of that firmware was inside gz archives that one could search the headers of.)

                  Now they (a) no longer use gz archives which makes writing an extraction script a little harder and (b) instead of writing the firmware into vram, it's instead DMA'd by the GPU from system ram. That means that mmiotrace no longer captures it. Instead we'd have to instrument it so that we capture the DMA command, and read the sysram containing the firmware ourselves. This would require a much more sophisticated tracer that no one's bothered to write yet.

                  Comment


                  • #10
                    Originally posted by imirkin View Post
                    Now they (a) no longer use gz archives which makes writing an extraction script a little harder and (b) instead of writing the firmware into vram, it's instead DMA'd by the GPU from system ram. That means that mmiotrace no longer captures it. Instead we'd have to instrument it so that we capture the DMA command, and read the sysram containing the firmware ourselves. This would require a much more sophisticated tracer that no one's bothered to write yet.
                    Why are they so against releasing firmware officially to begin with and go to these lengths to make it harder to extract? Just out of being jerks to mess up FOSS efforts?

                    Comment

                    Working...
                    X