Three days ago we passed along the latest information on the PSCNV driver
, which is a fork of the open-source Nouveau driver for NVIDIA graphics cards, with this information coming from Christopher Bergström of PathScale. As this was one of our first articles talking about the PSCNV driver at length, many readers were surprised by this fork with the upstream Nouveau driver still lacking even an official release. Some feel that this fork is a bad idea (it's even been compared to the dead RadeonHD driver
) while others are in support of PathScale's efforts. Since publishing that article we have learned a few more details on the PSCNV driver from some of its developers within our forums
For those that had not read our prior article on the PSCNV driver, it's a fork largely of Nouveau's kernel DRM driver. The company PathScale had forked the open-source DRM code so that they could gut TTM out of the driver and replace it with their own solution. TTM is the kernel memory manager within the mainline Linux kernel for GPUs (along with Intel's Graphics Execution Manager) that is used not only by Nouveau but also the Radeon and VMware drivers, among others. PathScale wanted to rid the Nouveau driver of GEM+TTM since in its current form is incompatible with OpenCL/CUDA and other GPGPU technologies due to it freely moving around buffers without notice. They also don't like TTM since it's more difficult to port to other non-Linux operating systems, among other reasons.
Unlike the upstream Nouveau driver that focuses upon providing some level of support for all NVIDIA GPUs, PSCNV only focuses upon the NV50 ASICs and later that are GPGPU-capable.
This PSCNV driver fork has been going on for several months already and they have already brought up 2D support for the NVIDIA GeForce GTX 400 "Fermi" series graphics cards. Those working on this open-source NVIDIA driver have also been extending the pool of documentation for NVIDIA hardware they have assembled through reverse-engineering.
For those wondering about PathScale's motives with working on an open-source Linux graphics driver -- seeing as they are a company specializing in proprietary compiler development for x86_64 clusters -- they are primarily interested in exploiting the compute capabilities (i.e. OpenCL) of the NVIDIA GeForce/Quadro hardware.
Martin Peres, who is involved with both the PSCNV and Nouveau drivers, has said
that the PSCNV work is mostly a fork of the kernel code. We have seen a xf86-video-pscnv DDX driver on PathScale's GitHub
, but Martin says it's mostly untouched and there really is just a one-line patch separating the two. That patch should eventually make its way back into the upstream xf86-video-nouveau X.Org driver. We will hopefully not see forked Gallium3D drivers for NVIDIA hardware. As far as any concerns go about the PathScale driver not being open-source friendly, Martin has said
, "The kernel driver, libdrm and the (very slightly modified) ddx are and will stay open source. As for mesa, they are working upstream as they have commit access."
From Martin's comment, PathScale is not only interested in GPGPU on NVIDIA cards, but to increase performance. In another comment
, we learned the creator of the NV50 Gallium3D driver is also working on the Fermi Gallium3D driver and he has been hired by PathScale for their project. Another comment from Peres: "We hope pscnv and nouveau will merge someday, but pscnv needs to experiment first" and at the same time "we are far from the merging point."
In terms of merging the PSCNV kernel code back into the Nouveau DRM, Bergström had commented that a few of the main Nouveau developers would need to be willing to let TTM get re-factored out, it would be a technical challenge to merge back the code as the two code-bases have already diverged quite a bit, and the graphics support for NV50 GPUs and earlier hardware would need to be improved.
About the comment made in the earlier PSCNV article about OpenGL 4.0 support being looked at for potentially next year, Christopher Bergström elaborated on it
, "The OpenGL4 comment was only a personal one. I would really love to see a community of developers make a todo list, plan and try to tackle this. I think within a year's time if it's broken down into small manageable pieces with good docs it can be done."
Read this thread
for the full discussion concerning the compute-focused PSCNV driver.