We Rely On Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained for the past 14 years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium. You can also consider a tip via PayPal.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.

1) pscnv for 2D Fermi is stable for one of our devs using it (I don't think it's been tested with gnome/kde though)
2) If you can find or figure out how to do a proper 2D benchmark then I'd bet we're faster. (by how much I don't know)
3) We still have a lot of work for some of the Fermi internals, but good progress is being made (If by any luck or magic it'll be "ready" by the end of the year)
4) 3D is still work-in-progress and most of the people on our team really dislike gallium so this may not improve unless someone steps up to help
5) The NV50 shader compiler was retargeted to NVC0 (This is mostly for testing purposes and gallium is of such low quality that I discourage the code from ever seeing the light of day)
6) With any luck or magic we'll soon have a complete set of timing data for nvidia.ko vs pscnv.ko at the instruction level. (I don't know of all of it will be public, but we'll likely post a summary of results)
7) We're putting together a lot of good docs - http://github.com/pathscale/pscnv/wiki/_pages

The important part of #5 is that they unified the shader/compute context with Fermi. This way as long as we're not causing a low level performance regression it only comes down to implementation of everything on top of it.. (eg is the shader compiler doing a good job.. is the CUDA generated code working as expected.. etc)

With the PSCNV kernel driver they have replaced the TTM kernel memory manager used by Nouveau with their own custom memory management solution. While TTM is living upstream in the Linux kernel along with GEM (the Graphics Execution Manager), PathScale wanted to do away with the TTM management since it offers no security or memory protection, TTM moves buffer objects around without notice (causing problems for OpenCL, CUDA, etc), and TTM is difficult to port to other operating systems. Nouveau also does command submission and synchronization within kernel-space, which is something opposed by the PSCNV developers due to extra kernel trips.

Unlike upstream Nouveau that seems to provide some level of support for all of NVIDIA's graphics cards past and present, PSCNV is particularly focusing upon the NV50 GPUs and newer. The NV50 ASICs (the GeForce 8 series) is well supported and newer while it's the GeForce GTX 400 "Fermi" support that's currently being tackled. Support for pre-NV50 ASICs may work, but it's not a target for the PSCNV developers.

According to the PSCNV GitHub page where much of this information can be found, the video memory management is done (GART though is not), there is PFIFP/PGRAPH setup and command submission completed, and other areas are still a work in progress. These include PFIFO/PGRAPH error handling, accelerated X.Org Server KMS support, and power management. They also have a TODO list of tasks.

In the email to Phoronix, Bergström also laid out for what he hopes the PSCNV / Nouveau development communities will tackle next calendar year. This hopeful work includes OpenGL 4 support, codec and video support, greater portability (*BSD, OpenSolaris, and potentially ReactOS), and to provide a highly-optimized shader compiler.

Seeing OpenGL 4.0 support in any open-source Linux driver is perhaps quite ambitious with all of the current drivers being stuck at OpenGL 2.1 or less until OpenGL 3.x support in Mesa is figured out and coded (there's legal issues potentially holding it up), but if the support comes to fruition in 2011 for OGL4 that would be terrific.

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter or contacted via MichaelLarabel.com.

The mission at Phoronix since 2004 has centered around enriching the Linux hardware experience. In addition to supporting our site through advertisements, you can help by subscribing to Phoronix Premium. You can also use our NewEgg.com shopping links when making online purchases or contribute to Phoronix through a PayPal tip.