Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

Thread: The State, Direction Of The PSCNV Nouveau Fork

  1. #1
    Join Date
    Jan 2007
    Posts
    15,127

    Default 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. #2
    Join Date
    Jun 2007
    Location
    The intarwebs
    Posts
    385

    Default 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?

  3. #3
    Join Date
    Dec 2009
    Posts
    110

    Default

    Quote 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?

  4. #4
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    184

    Default

    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.

  5. #5
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    536

    Default

    Quote 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.

  6. #6
    Join Date
    Oct 2009
    Posts
    60

    Default

    Quote 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.

  7. #7
    Join Date
    Jan 2009
    Posts
    191

    Default

    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.

  8. #8
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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 <_<'

  9. #9
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    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.

  10. #10
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote 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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •