Announcement

Collapse
No announcement yet.

NVIDIA GeForce 400 "Fermi" Series On Nouveau

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

  • NVIDIA GeForce 400 "Fermi" Series On Nouveau

    Phoronix: NVIDIA GeForce 400 "Fermi" Series On Nouveau

    With NVIDIA still not providing any open-source support or technical documentation for their graphics processors, for those in the open-source community who seek to use their GeForce 400/500 "Fermi" GPUs without NVIDIA's binary driver, they are left to use the reverse-engineered, community-created Nouveau driver. Fortunately, the support for the NVIDIA Fermi GPUs is coming along at a respectable pace -- with even working OpenGL acceleration -- considering that NVIDIA is providing no support at all. In this article are the first benchmarks of this experimental GeForce 400/500 "Nouveau NVC0" driver versus NVIDIA's official proprietary driver.

    http://www.phoronix.com/vr.php?view=15851

  • #2
    Tests with over 500 fps

    are quickly entering the glxgears "this is not a benchmark" territory. At least, not a useful one.

    Comment


    • #3
      Please compare the cards at the same clocks

      Hey Michael,

      I'm glad you managed to extract the firmware yourself. Anyway, Fermi has no open-source reclocking support yet, you should warn users that the card was run at the default frequency vs full speed for the blob.
      All the info you need are in the latest nouveau companion: http://nouveau.freedesktop.org/wiki/...0galliumdriver

      As you can see, when reclocked nvc0's performance is quite high

      Also, the performance boost you've seen on nouveau isn't due to the pageflip. Pageflip only brought a little performance improvement by itself. That's what I tried to explain in the latest nouveau companion:
      current: 90 fps, nvc0-branch: 140 fps, +zcomp: 170 fps, +pageflip: 190 fps

      The nvc0-branch has been merged to mesa master some time ago.

      One last thing, please reclock the nv50 cards if you want to test the performance of the driver. Drop me a line and I'll tell you what to do and all the warnings I should give you (no temperature/fan management at the moment).

      We hope Linux 2.6.40 will ship some nice PM improvements

      Comment


      • #4
        Originally posted by MPF View Post
        ... you should warn users that the card was run at the default frequency vs full speed for the blob.
        That must be where the tenfold increase in performance is coming from

        I particularly enjoyed this part (from the link you mentioned):

        if you want open 2D/3D acceleration on nVidia cards, you need to use KMS and nouveau.

        If nouveau crashes your computer, you can:

        Try to deactivate the hardware acceleration

        Comment


        • #5
          Originally posted by bug77 View Post
          That must be where the tenfold increase in performance is coming from

          I particularly enjoyed this part (from the link you mentioned):
          Of course, when memory is downclocked by a factor ten, performance goes down by the same factor

          As for what to do when nouveau crashes your computer, this is extreme but still better than using VESA
          Anyway, this shouldn't happen. If it does, one should notify us on #nouveau (freenode) or freedesktop's bug tracker.

          Comment


          • #6
            Clocks

            The "rendering problems" you're seeing are not rendering problems, I call them "page jumping", it's a mysterious bug where the virtual -> physical address mapping seems to be temporarily ... confused.

            And about clock speeds, the lowest performance level with the blob on my GTX470 is 50 MHz core clock. 50. And the highest is 600+ MHz. I'm not sure at which frequency the BIOS puts the card, but if it's anywhere near the lowest level there's still much potential there.

            At least mesa demos/perf/fillrate goes up by an actual factor of 10 on that card with nouveau when I let the blob clock it up and then do a forced kexec to not give it a chance to lower them again.

            Comment


            • #7
              NVidia

              I know NVidia wouldn't take part in all this, but I think they could and SHOULD help solving some HW locks there. I gues their HW-debugging equipement would solve these easily. Anyway, I am sure they will readily steal ideas from Nouveau as soon as they figure it is faster then their regular Windows driver :-)

              Anyway, thanks to Nouveau guys for amazing work.

              Comment


              • #8
                Who...

                needs 600 fps? I mostly play RPGs...
                I'll definately try the open source driver (my new laptop arrived yesterday in the country )

                Comment


                • #9
                  i don't understand why people are acting like (or hoping) nvidia may some day be obligated to contribute to the open source drivers. that obviously is never going to happen. unlike amd and intel, nvidia has something to hide - cuda. once people can figure out how cuda works on the driver level, people can use it for amd and intel GPUs, and once THAT happens, nvidia will lose money on something that is no longer exclusive to them. i'm not saying that i agree with this, but its completely understandable.

                  there is the idea that nvidia could still make open source drivers that will ONLY work with opengl and direct3d (if that ever comes to linux) with no cuda support at all, but, unlike amd/ati, nvidia actually keeps up fairly well with their linux drivers compared to their mac and windows drivers. nvidia doesn't need people complaining about how their drivers aren't up to date; if they make the drivers themselves, it will (or should be) working and fast. if nvidia left the drivers up to the community, things would take too long to get working and efficient.

                  as far as i'm aware, amd plans on making their drivers open source. since their drivers are already inadequate, they aren't really losing anything if they hand their stuff over to open source developers.

                  i'm all for open source drivers and i admire the results so far, but i strongly feel there NEEDS to be proprietary drivers on such complex hardware. nvidia is already paying people to make linux drivers. sure they could contribute to the open source drivers but i feel like if they do both (with proprietary being cuda compatible), thats asking a little too much from them for an operating system with a small percentage of desktop users.

                  Comment


                  • #10
                    Originally posted by schmidtbag View Post
                    i don't understand why people are acting like (or hoping) nvidia may some day be obligated to contribute to the open source drivers. that obviously is never going to happen. unlike amd and intel, nvidia has something to hide - cuda. once people can figure out how cuda works on the driver level, people can use it for amd and intel GPUs, and once THAT happens, nvidia will lose money on something that is no longer exclusive to them. i'm not saying that i agree with this, but its completely understandable.

                    there is the idea that nvidia could still make open source drivers that will ONLY work with opengl and direct3d (if that ever comes to linux) with no cuda support at all, but, unlike amd/ati, nvidia actually keeps up fairly well with their linux drivers compared to their mac and windows drivers. nvidia doesn't need people complaining about how their drivers aren't up to date; if they make the drivers themselves, it will (or should be) working and fast. if nvidia left the drivers up to the community, things would take too long to get working and efficient.

                    as far as i'm aware, amd plans on making their drivers open source. since their drivers are already inadequate, they aren't really losing anything if they hand their stuff over to open source developers.

                    i'm all for open source drivers and i admire the results so far, but i strongly feel there NEEDS to be proprietary drivers on such complex hardware. nvidia is already paying people to make linux drivers. sure they could contribute to the open source drivers but i feel like if they do both (with proprietary being cuda compatible), thats asking a little too much from them for an operating system with a small percentage of desktop users.
                    Too bad, CUDA has been Reverse Engineered long ago

                    Comment


                    • #11
                      Originally posted by MPF View Post
                      Too bad, CUDA has been Reverse Engineered long ago
                      really? where can you get it? also how good is it? btw i'm legitimately interested, i'm not saying you're wrong. i feel like if theres an open source cuda then it'd be compatible with amd and intel GPUs.

                      Comment


                      • #12
                        Originally posted by schmidtbag View Post
                        really? where can you get it? also how good is it? btw i'm legitimately interested, i'm not saying you're wrong. i feel like if theres an open source cuda then it'd be compatible with amd and intel GPUs.
                        It has been *just* REed (hardware-side), you'll have to wait for an open source CUDA.

                        OpenCL is meant to be portable, why would we implement CUDA for AMD?

                        Comment


                        • #13
                          Originally posted by MPF View Post
                          It has been *just* REed (hardware-side), you'll have to wait for an open source CUDA.

                          OpenCL is meant to be portable, why would we implement CUDA for AMD?
                          lets hope phoronix can tell us more about the open source cuda in the future. i'm a big fan of opencl, but the main reason cuda would be great for amd is because of the cuda programs that already exist. opencl seems a little less polished and has less programs. also, people could then do physx with amd. i know linux probably won't benefit much from that but windows could probably learn from the open source nvidia drivers.

                          Comment


                          • #14
                            Originally posted by MPF View Post
                            It has been *just* REed (hardware-side), you'll have to wait for an open source CUDA.

                            OpenCL is meant to be portable, why would we implement CUDA for AMD?
                            make sure to wait until Nvidia release their ARM gfx driver's into the mobile market though, i suspect some of this RE will come in handy over there too if its code is not made to public and wide spread before then, so they have a reason and time to patch/block it before a first mass ARM Nvidia driver release then perhaps making everyone's RE effort even more useful.

                            BTW what was REed , did they do the closed microcode loading, that could be fun, loading a few of your own enhanced CPU like opcodes into the thing LOL

                            Comment


                            • #15
                              Originally posted by popper View Post
                              make sure to wait until Nvidia release their ARM gfx driver's into the mobile market though, i suspect some of this RE will come in handy over there too if its code is not made to public and wide spread before then, so they have a reason and time to patch/block it before a first mass ARM Nvidia driver release then perhaps making everyone's RE effort even more useful.

                              BTW what was REed , did they do the closed microcode loading, that could be fun, loading a few of your own enhanced CPU like opcodes into the thing LOL
                              Nvidia doesn't care about us REing, really. We know how to compile a CUDA program and execute it on the hardware, that's all I can tell (I haven't worked on the GPGPU side yet).

                              Comment

                              Working...
                              X