ATI R300 Mesa, Gallium3D Compared To Catalyst

[V!NCENT]

The switch from wanting to contributing doesn't happen overnight... Hello World != coding a GPU driver you know...

[pingufunkybeat]

Well, the GPU drivers are obviously suffering from the lack of community contributions. Of course, there is significant work being done by a number of community developers, but I don't think that it's realistic to expect the GPU drivers to be written 95% by the community, like many large FLOSS projects are.

I think that Gallium3d is a step in the right direction. It centralises lots of the technology, so it is much more reusable. It should make writing drivers easier. But I'm guessing that we'll still be dependent on the manufacturers for much of the basic infrastructure work for new GPUs.

The reason why open drivers lack behind the closed ones is that writing GPU drivers is not easy, and takes lots of manpower.

[yotambien]

It's hard to tell whether relicensing the graphics stack to GPL would attract more developers.[...]

On the other hand, the more liberal license of the graphics stack has not yielded in any significant contributions from the BSD camp.[...]

It's not about developers, but about users (that's you). There's a reason why the licenses are either MIT or LGPL. Programs (thus users) have to use those libraries, regardless of what license those programs are written on. Or else you won't play much Q3 with the OSS drivers.

[Svartalf]

I realy like to contribute code somewhere in/to the driver stack. I realy dislike doing so in non-gpl but then again this is not a solo show and thus arguing about the more liberal license is just... totaly stupid/futile/egocentric/etcetera.

Heh... You'll note there was this 3D stack for Linux that precedes the current DRM framework, called Utah-GLX. It was licensed under the MIT/X11 license. I was one of their contributors/maintainers for a long while.

Did I mention I prefer LGPL and usually release stuff under it and the GPL?

Your reasoning is why I did what I did and would do it again, in light of things.

[Svartalf]

The switch from wanting to contributing doesn't happen overnight... Hello World != coding a GPU driver you know...

Definitely not. It's a brutally hard thing, requiring roughly the same level of ability as keeping up with the key people in lkml. There is a reason why it's slow. There is a reason why the Linux AMD proprietary driver has been very dodgy in the past.

[Svartalf]

It's not about developers, but about users (that's you). There's a reason why the licenses are either MIT or LGPL. Programs (thus users) have to use those libraries, regardless of what license those programs are written on. Or else you won't play much Q3 with the OSS drivers.

Actually, if it's LGPLed only, it'd not impact the users at all.

It really is more about the pool of available people willing to do the work and have the right skills to do it. It's not an easy thing doing this stuff- and at least until Gallium's done, you're going to need a developer at least a couple of cuts above average to do the work.

[Svartalf]

Well, the GPU drivers are obviously suffering from the lack of community contributions. Of course, there is significant work being done by a number of community developers, but I don't think that it's realistic to expect the GPU drivers to be written 95% by the community, like many large FLOSS projects are.

One could say the same thing about the OS itself.

I think that Gallium3d is a step in the right direction. It centralises lots of the technology, so it is much more reusable. It should make writing drivers easier. But I'm guessing that we'll still be dependent on the manufacturers for much of the basic infrastructure work for new GPUs.

The basic infrastructure's amazingly similar in nature for most GPUs.

It's going to be more in knowing where the vicious pinch-points are within the architecture of a given chip- and then avoiding them when you're feeding command streams to it. We're going to probably start seeing incremental boosts in performance with the FOSS Radeon support here in a little bit as the final pieces of Gallium seem to be gelling. This would be them removing things that bottleneck the GPU or the CPU at the worst possible times. All it takes is a 1msec stall in the pipelines to drag you to the floor in framerates on things.

You might need the vendor's help on that part, you might not.

The reason why open drivers lack behind the closed ones is that writing GPU drivers is not easy, and takes lots of manpower.

I would hesitate to say "lots" of manpower, but it certainly takes more highly skilled people than are available right now- whether you're talking about AMD's fglrx or the FOSS Gallium stuff.

[pingufunkybeat]

If I'm not mistaken, both the FGLRX and the Nvidia driver teams number quite a few full-time developers.

I don't know if it qualifies as "lots of manpower", but it's probably far more than the number of people working on FLOSS drivers full time. And they have 15 years of accumulated optimisations and a large head start on top of that.

[Svartalf]

If I'm not mistaken, both the FGLRX and the Nvidia driver teams number quite a few full-time developers.

There's less on the AMD side than the NVidia side right at the moment, but the point's taken.

I don't know if it qualifies as "lots of manpower", but it's probably far more than the number of people working on FLOSS drivers full time. And they have 15 years of accumulated optimisations and a large head start on top of that.

No, it really doesn't qualify as a "lot of manpower" on the side of the equation we're talking about- but the cumulative years of experience on what to/not to do with this stuff does offset that some. Once you hit a certain threshold, though, they become a bit more obvious and clear with observation of what's going on when you do <X> within the driver. It took me about 6 months to start beginning to get "useful" with my client's Windows side sustaining engineering work (Doing OpenGL drivers, mind...)- at which point the contract was up and they didn't have budget to continue with me and one other contractor working for them. This was picking up the knowledge that we're discussing here and then trying to make use of it to fix busted applications.

The same will be probably true for the Gallium driver framework once the whole thing gels and they start doing the other part of that learning curve. It'll take a bit longer than I took to get up to speed with things on my contract, mainly because they won't have full access to the knowlege base I had (One of the OpenGL ARB reps and a co-author of one of the best books on OpenGL was my boss while I was working there...) but it will come and you will start getting a few more people interested once they see it's repeatable (right now it's a lot harder work than it needs to be because you're duplicating things within each of the drivers available- which makes it difficult to optimize anything or fix a range of issues in the driverspace...).

[V!NCENT]

Don't confuse yourself with the blobs. We are talking about a shitload of "must work now!", complexity due to legacy and then changing and achanging the codebase, undecrypted processing all acros the board, coding while not even finnished [gpu], sorting out errors, zero creativity due to zero legal limitations, not something they believe in (proprietary), deadlines, win/mac/linux environment with different interfaces and meetings, etc, etc, etc...