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)
For those not familiar with PSCNV, as said in the introduction it's a fork of the Nouveau kernel driver being done by PathScale, the company that specializes in compilers. PathScale previously said they would port Nouveau to OpenSolaris (thought the state of this work is presently unknown) and they have also offered to buy Fermi graphics cards for open-source developers interested in working on the support.
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.
More information to come soon.