Is there any cross-pollination with the OSS drivers?

[EmbraceUnity]

With all this news about Gallium3D, GEM, etc I'm just wondering if any of this is at all relevant to Catalyst.

With more graphics stuff entering the mainline kernel, it seems only natural that there may be some performance benefit. Also, Gallium3D will make it much easier to support new graphics APIs.

What's the scoop?

[RealNC]

Gallium3D will be worse than NVidia's/ATI's proprietary solution. So I bet they won't use it. GEM is also useless to them because their proprietary manager is faster than GEM.

There's one thing you didn't mention that *would* help the binary drivers: UXA/EXA (should eliminate the lag in compositing) and maybe DRI2. I hope ATI has plans to support UXA/EXA soon in Catalyst :P

[TechMage89]

Actually, according to bridgman, ATI's internal implementation of their driver works quite similarly to Gallium3D (It would be nice to have access to the lower level API, but I guess there are legal issues with that.)

ATI is implementing something they call "TexturedXRender" which I believe is a bit similar to EXA, or at least the render acceleration portion. It's also rumored that the driver coming out in January will implement a DRI2-like technology. That said, the binary drivers are all a blob so they sort of do their own thing, and don't make much use of open apis.

[RealNC]

ATI is implementing something they call "TexturedXRender" which I believe is a bit similar to EXA, or at least the render acceleration portion.

In any case, it's awful. We want support for speedy compositing. Opening menus or maximizing windows among other things with KDE4 or Compiz is slow as hell

The open source drivers don't have this problem; compositing is super fast and fluid there with EXA.

[TechMage89]

Right, TexturedXRender is still experimental and not very well optimized. Hopefully they'll implement proper EXA at some point. Honestly, though, I don't hold out a lot of hope for closed-source drivers. I'm waiting the open-source driver to be a total replacement (on my x1600 for my purposes (I don't do much gaming on Linux) it already is). Now that the r600/r700 code is out, too, I it shortly will be for most people.

[RealNC]

I, on the opposite, don't have much hope for the open source drivers. They're simply too slow and ATI/NV want to keep it that way due to competition. I honestly believe that open source drivers will always be at least an order of magnitude slower then the proprietary ones when it comes to rendering performance. In other words, they will be a total waste of the performance of the hardware they run on. In other-other words, crippled

AMD's open source initiative is better than nothing, but they did never fully embrace the open source development model. If they did, Catalyst would be open sourced or at least shared sourced.

[RobbieAB]

AMD's open source initiative is better than nothing, but they did never fully embrace the open source development model. If they did, Catalyst would be open sourced or at least shared sourced.

And we come back to this point...

What if there is stuff in Catalyst AMD don't own the rights to? What if there is stuff in Catalyst AMD are contractually bound to keep secret?

At the end of the day, AMD have been giving the Open Source community exactly what we spent years asking for: Hardware specs. Now it's down to US to deliver on our side of that bargain before we bitch them out even more, which means WE deliver the drivers...

[bridgman]

I, on the opposite, don't have much hope for the open source drivers. They're simply too slow and ATI/NV want to keep it that way due to competition. I honestly believe that open source drivers will always be at least an order of magnitude slower then the proprietary ones when it comes to rendering performance.

Heck, even I don't believe that. I think you will see perhaps 50% of the 3D performance within a year, which is less than the difference from one model to another within a GPU family (rv610 to rv630 to rv670 is more like 1:3:8).

If you mean "we don't want to open up all of our proprietary driver code because we don't want to hurt our ability to compete in the Windows and MacOS markets" there is obviously some truth to that, since most of the code is common across multiple OSes. If you mean "we don't want the open source drivers to compete with fglrx" then my answer would be more along the lines of "(cough) bulls***"

The bottom end of the open source driver stack is already being rewritten to remove the worst of the performance bottlenecks (mostly related to the way synchronization between driver and GPU is handled). Integrating a decent memory manager into the 3D stack will allow a lot more optimizations, and moving from the current Mesa hw driver architecture (which was designed around fixed function GPUs) to Gallium3D will enable another round of speed increases.

It's going to take a lot of work to bring the open source driver stack up to the same level of architectural sophistication as the proprietary drivers, but the work is being done now and is making good progress. It just isn't going to happen overnight -- we're talking about a significant rewrite of a couple million lines of code and a lot of the work needs to be done in common code rather than vendor-specific or GPU-specific code.