Announcement

Collapse
No announcement yet.

The State, Direction Of The PSCNV Nouveau Fork

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

  • The State, Direction Of The PSCNV Nouveau Fork

    Phoronix: The State, Direction Of The PSCNV Nouveau Fork

    Christopher Bergström of PathScale has passed along a note detailing some of the recent progress made by the Nouveau team and their developers working on PSCNV, their Nouveau driver fork. This includes 2D beginning to work on the GeForce 400 "Fermi" graphics hardware, open-source 3D for Fermi still being worked on, and a pool of documentation is beginning to form for the NVIDIA hardware by the open-source community. Here's the details in full...

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

  • #2
    Uh...

    Look, I'm willing to lose 20% of my OpenGL performance if it means I get Direct3D, video decoding, OpenCL, and whatever else, open sourced, in a timely manner.

    How about they support something new and interesting, like Poulsbo?

    Comment


    • #3
      Originally posted by ethana2 View Post
      How about they support something new and interesting, like Poulsbo?
      How can Poulsbo be newer and more intresting then Fermi?
      And even more how for a company working on a Nvidia-driver and not a PowerVR/Intel-driver?

      Comment


      • #4
        They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.

        Comment


        • #5
          Originally posted by Zajec View Post
          They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.
          My thinking exactly.

          I hope they don't go around re-doing everything because they think "it sucks" and their work just gets lost on it all, or gets very hard to use because they patch things everywhere.

          Comment


          • #6
            Originally posted by Zajec View Post
            They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.
            This fork smells like Reiser4 all over: PathScale may come up with something which performs on a Fermi GPU, but their efforts do not seem to be very well integrated with the rest of the open source crowd. Nobody will want to include it later since it is incompatible with the current state of kernel and X.Org, and nobody will want to support it when PathScale decides to no longer work on it one day. And they already started insulting people ("Gallium has very low quality" etc.). GREAT move, PathScale! Did Hans Reiser not teach you anything?

            Since all the things they point out in TTM seem fixable to me, and Nouveau already supports quite some stuff on NV50, why don't they just branch both projects and work with the community? Would probably take a bit longer, but if they really come up with something working until the end of the year it will probably already be included in the next bigger distributions (Ubuntu 10.04, Fedora 15). Nobody will want to include a fork, since PSCNV does not support older hardware distributions would even have to deliver Nouveau AND the fork, and make sure they don't block each other.

            Comment


            • #7
              looks like radeonhd not taught them that incompatible user-alienating ununified community-dividing graphic driver forks are shortliving, useless and disrupting.
              gallium maybe not a saviour of all humanity but it's a way most developers and users want things done, and in current state of nouveau, fork is the last thing it needs :\

              it also looks like they just want not to have troubles porting GNU/Linux driver awesomeness on those other OS's and reinventing bicycle again. of course they will not have skill or resources to do it single-handedly and no one going to help them. good fucking luck.

              Comment


              • #8
                They probably looked at Fermi and wondered how much this card could perform and Gallium3D probably wasn't helping them in their ultimate vision.

                If only they could stop staring at their car navigation and realise that the world does not revolve around them <_<'

                Comment


                • #9
                  I really don't understand the point of this fork.

                  I'm sure that they're not stupid, and that there may be technical reasons for reinventing the wheel, but they must be aware that this sort of insular development isolated from most of the OSS community is usually doomed from the outset.

                  Comment


                  • #10
                    Originally posted by pingufunkybeat View Post
                    I really don't understand the point of this fork.

                    I'm sure that they're not stupid, and that there may be technical reasons for reinventing the wheel, but they must be aware that this sort of insular development isolated from most of the OSS community is usually doomed from the outset.
                    Indeed, well, reimplementing a new memory manager isn't so much of a problem as the GEM interface is still being used.

                    We are not forking everything, only the kernel side (and most of the code remains shared). The ddx is left (almost) untouched (there is a one-line patch) that can eventually get merged in the mainline ddx.

                    The point of all that is to get GPGPU on nvidia cards (TTM is incompatible with GPGPU without some modifications as it assumes you can safely move the buffers. Of course, you wouldn't expect your pointers to move in your standard C code.) and to increase performance (on some selected 2D-tests I made, we were _up to 50% faster_ than the blob. There is still a lot of work to be done though.

                    I try to work for both Nouveau and pscnv and I can assure you both projects benefit from each others. The hard work is reverse engineering, and this work is still shared.
                    Come on guys, please have a look at HMPP (http://www.caps-entreprise.com/fr/pa...p?id=49&p_p=36) and get exited by it

                    Comment


                    • #11
                      I don't think PathScale has any intention of creating a generally useful driver for the benefit of the community at large. Specific people may find specific advantages for a limited set of hardware (NV50 or newer), but they seem uninterested in the 3d stack. They then tell us that they're looking to add OpenGL 4 support, which is an extremely dubious claim, even for a big company. What, are they just going to build their own 3d driver from scratch on top of their own custom kernel memory manager? How many people do they have working on this project?

                      And a compiler company, to do all this? Maybe they should stick with compilers for the CPU. They don't seem to understand how the open source world (or the graphics device driver world, for that matter) works.

                      But hey, people who want really fast 2d on their new awesome $500 Fermi card can grab pscnv and be amazed at the glorious non-composited desktop (that a $15 Intel chip can do equally well)...

                      Comment


                      • #12
                        Originally posted by allquixotic View Post
                        but they seem uninterested in the 3d stack. They then tell us that they're looking to add OpenGL 4 support, which is an extremely dubious claim, even for a big company.
                        Hey, we never told OpenGL 4 would be supported, it was a wild guess from Michael I guess.
                        Well, the main creator of the gallium driver for nv50 is working on the gallium driver for nvc0. Guess what, he is hired by Pathscale

                        Don't worry, people at Pathscale understand the value of the community. This is why, even though Pathscale's business is high-performance computing for companies, they value accelerated X and 3D support on nvidia cards (Fast 3D support requires a good GLSL compiler with a real good code generation, doesn't it?)

                        Comment


                        • #13
                          Originally posted by MPF View Post
                          Indeed, well, reimplementing a new memory manager isn't so much of a problem as the GEM interface is still being used.

                          We are not forking everything, only the kernel side (and most of the code remains shared). The ddx is left (almost) untouched (there is a one-line patch) that can eventually get merged in the mainline ddx.

                          The point of all that is to get GPGPU on nvidia cards (TTM is incompatible with GPGPU without some modifications as it assumes you can safely move the buffers. Of course, you wouldn't expect your pointers to move in your standard C code.) and to increase performance (on some selected 2D-tests I made, we were _up to 50% faster_ than the blob. There is still a lot of work to be done though.

                          I try to work for both Nouveau and pscnv and I can assure you both projects benefit from each others. The hard work is reverse engineering, and this work is still shared.
                          Come on guys, please have a look at HMPP (http://www.caps-entreprise.com/fr/pa...p?id=49&p_p=36) and get exited by it
                          Looking at HMPP, it seems like GPGPU on recent hardware is the primary focus of this project. That's fine, but if you look at the question "Which tasks do you actively engage in?" at Phoronix's 2010 Linux Graphics Survey Results, GPGPU is dead last, by a large margin. What you are building will be primarily interesting to people in the HPC sector, companies such as Pixar, and enthusiasts/developers. The focus on the compute pipeline will almost guarantee that the 2d/3d graphics rendering work will get a secondary priority, so quite frankly I am extremely skeptical of OpenGL being supported in the near future. This driver's whole purpose has been pointed squarely at GPGPU, so you can't just open up your repositories and wait for the patches to magically fly in implementing GL for you. The people who do contribute will be contributing to the direction you've already started down; i.e., GPGPU.

                          And HMPP is proprietary software, so it looks like your interest is in enabling this open source driver to actually outperform the proprietary NVidia driver, with the goal of selling more licenses of your proprietary software. Nice, but again, this is not something that will appeal to the open source community.

                          Good luck to you guys, I'm sure you will sell some licenses to some big-name companies for this, but don't expect much in the way of community enthusiasm or opportunities for making it to the mainline Linux kernel.

                          Comment


                          • #14
                            poor choice of words

                            I don't mean new and interesting hardware wise, but I can see that's more or less what I said.. I mean, we *have* an open source driver for these new nVidia cards, I'm using it right now with 3d acceleration. We don't have a good one for poulsbo.

                            Comment


                            • #15
                              It's not that I hate PathScale's effort; I am just disapoint(ed). It does contribute to nVidia documentation, but given that nVidia doesn't co-operate I whish that they just bankrupt themselves.

                              Comment

                              Working...
                              X