The State, Direction Of The PSCNV Nouveau Fork

[allquixotic]

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

[MuPuF]

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

[allquixotic]

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.

[ethana2]

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.

[V!NCENT]

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.

[MuPuF]

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.

Of course, pscnv is meant for HPC. This driver is for performance enthusiasts. Fast 2D support is a good start (I used to work on this before switching to Power Management), I'll return at it in the future. I personally want the snappiest desktop possible out of my hw, who doesn't?

The gallium drivers works on pscnv, working on gallium will automatically target both pscnv and nouveau. So far, Pathscale has been working only on gallium for 3D even though they don't believe at all in the IR (they are not the only ones, see the guy from vmware who wants to replace it also).

[Lynxeye]

OpenSource development is in many cases driven by companies with a financial interest in the software. So yes, pscnv is developed with GPGPU in mind but nouveau will also benefit from this effort. Mainline nouveau even has the interfaces to plug in an other in kernel memory management.

The reverse engineering work is shared between pscnv and nouveau and the 3D drivers will also benefit if we are able to do bindless graphics with the new pscnv mm backend.

Pscnv has no ambitions to go into the kernel. It is just a playground for developers to free some ideas. If we want this stuff in kernel we can always merge it back to nouveau, because pscnv is a friendly fork. No reason to bash.

[MuPuF]

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.

Ack, they deserve it.

But nVidia cards really are well designed and are the currently most used ones :s

I felt like you until I received a free laptop from my school with an nvidia card. I had to choose between slow 2D support and the latests kernels or the feature-full almighty blob.

Nouveau has been a great fit so far and I hope Pathscale's effort will help improve the open source support of these cards.
Look, they already provide accelerated X on Fermi and trust me, Fermi changed _a lot of things_!

[allquixotic]

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

Oh, the OpenGL 4 thing was a Michael guess? I take it the "ReactOS" mention was also Michael?

Heh... the article makes it seem like Christopher Bergstr?m wrote "OpenGL 4" in his email:

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

So the article was worded in a misleading manner, and in fact OpenGL 4 was not claimed as being on the todo list. That's fine. See, that is good for PathScale, because it just shows that you guys are being honest about what you think you can realistically accomplish, and what your priorities are. Making outlandish claims that you don't follow up on just makes you seem like a fool. Thankfully, this was Michael's words, not PathScale's, so you guys are off the hook on that

But without even a plan for OpenGL 4 support, that just further solidifies the stance that this driver is not targeted to mainstream users, and indeed will not be very useful to them compared to either nouveau mainline, or the proprietary nvidia driver. Unless you plan on implementing an older version of the OpenGL spec instead? 2.0? 2.1? (Neither you nor Michael mentioned that, so I won't assume anything).

(Fast 3D support requires a good GLSL compiler with a real good code generation, doesn't it?)

Yes, it does. But there are three "minor" problems:
(1) Complete OpenGL support (at any version) requires a great many things that have nothing to do with shaders, and everything to do with poking registers on the hardware. In many cases, trying to shoe-horn these things into a shader pipeline will just reduce your performance dramatically, since the hardware optimized to perform that specific task is best-suited to doing so, without loading down the centralised general-purpose resource (shader cores). These are graphics-specific features that will not magically get implemented by having a fantastic compiler targeted at NVC0 GPGPU.

(2) What's "fast" for GPGPU is not necessarily fast for 3D. For instance, the volatile nature of TTM's BO management is actually an optimization feature. The cost of the buffer management (moving/evicting buffers) is intended to be an amortized cost so that the overall performance of the system for 3d and intensive 2d tasks is improved. The simple fact that GPGPU requires your pointers to not move around is a design restriction imposed on memory managers implementing GPGPU, which, if imposed equally upon the 3d pipeline, will reduce performance there. At least, this is how I understand the rationale behind why TTM is implemented the way it is today. After all, logic says that it is much easier to implement a buffer management system that does not move around buffers or evict them at all (because the natural state of an object in memory is to remain in a fixed location); the fact that they have had to implement a buffer manager that does move/evict BOs demonstrates that there is a design or performance incentive to do so. This performance incentive may only apply to 3D, but in my opinion, that's perfectly fine (seeing how I use 3D extensively, but never use GPPGU).

(3) There are a great many users of Nvidia cards pre-NV50, and these cards will continue to be used for many years. Some of them are still being sold new in retail stores in some countries. Users of these cards want fast 2D and 3D. But since their card is incapable of supporting GPGPU hardly at all, your work does not apply to them. It is fine if this doesn't bother you at all, but realize that this will be one of the main resisting forces from the community (and distro adoption, similarly) to ensure that your driver remains a niche driver for HPC professionals.

It's neat that PathScale is trying to reach out to the community and claims to understand the appeal of cooperating with the community... and I think you've been successful in that, to the extent that people are aware of your company, aware of what your driver's intention is, and don't hate you for it. After all, you guys aren't really doing anything evil; you're just working on a driver for your own particular needs, and the needs of a few others. To those who find this useful, all power to you! And thanks for writing open source software (at least as far as your driver is concerned; "booooo!" for HMPP )

[niick]

I personally think this all sounds like good news for nouveau. Whilst I don't use any GPGPU/CUDA the work going on sounds broad enough to touch parts of the driver I am interested in like reliability, 2D (and video acceleration?).

One question though is that if your efforts are successful and you improve certain aspects of the driver will the two projects ever merge back together. If not why not? I don't have the knowledge of the details but it seems that Pathscale doesn't like some current aspects (TTM) and are re-implementing them. Are there any downsides to this approach? If not then why wouldn't the projects eventually settle on the superior solution and merge.

I think people who are using nouveau might mistake this as something being lost rather gained, but from what I've read it seems more like a win win.

Also could some elaborate on what the problems are with Gallium, I was looking forward to the day when Gallium matured and a flood of state trackers meant my computer was doing all kinds of neat stuff.