AMD, please give us EGL or decent direct rendering.

[sgprince]

Why Bother with AMD/ATI?

Frankly, I would not recommend AMD GPU, full stop. Please dump or disable it and go get a Nvidia GPU.

[Rallos Zek]

Frankly, I would not recommend AMD GPU, full stop. Please dump or disable it and go get a Nvidia GPU.

If you use Linux and buy Nvidia you are shooting yourself in the foot. Nvidia is no friend of free software, whilst AMD time and again shows that they want to work with us who use FOSS.

When buy AMD you are helping FOSS and Linux, when you buy Nvidia you are supporting all things proprietary.

[entropy]

If you use Linux and buy Nvidia you are shooting yourself in the foot. Nvidia is no friend of free software, whilst AMD time and again shows that they want to work with us who use FOSS.

When buy AMD you are helping FOSS and Linux, when you buy Nvidia you are supporting all things proprietary.

Well, that's the ambiguity of the word 'support'.

There are people claiming that Nvidia has the best Linux support,
while other point out that they're not supporting Linux at all.
Strange enough, it seems they both have a point.

[Panix]

If you use Linux and buy Nvidia you are shooting yourself in the foot. Nvidia is no friend of free software, whilst AMD time and again shows that they want to work with us who use FOSS.

When buy AMD you are helping FOSS and Linux, when you buy Nvidia you are supporting all things proprietary.

The FOSS driver is not 100% optimized as has been explained and discussed over and over. Performance wise, I try to recall the figure but for e.g., 70% of the binary performance. For some, that is enough but not necessarily everyone.

I think if you are lacking features and performance, then one can be justified at considering options that allow for full performance and features.

The same features continue to be absent in the open source driver (look at the radeon feature matrix) and the performance is not fully optimized so obviously, it's not 100% open and the resources invested are lacking. It is just a matter of opinion whether you accept this caveat and can live with it.

Even though the proprietary driver is vilified here, if one buys a brand new card, they expect full features and performance, whatever the card can do. Unfortunately, the benchmark or comparative scale is via the latest Windows OS. But, these hardware companies are catering their editions to MS and the MS OS. Unless the open drivers are open to the point in which there is full openness to go from, there is always restrictions. So, it's based on tradeoffs?

Also, buying the AMD card, one is expected to bug track and troubleshoot if you want to contribute to the expanding improvement? It's a good idea but I am curious what time and expertise is needed... there is not as much investment from the company itself so you are expected to do a significant share.

Also, the improvement or progress of the FOSS driver is not motivated by money as much as the proprietary so there is a positive and negative benefit to that.

[zappa86]

I find the discussion of which company (AMD or Nvidia) supports linux better and how they do it as interesting as the next person, but lets stay on topic here. Were discussing the fglrx and what needs to be done to improve it.

[markg85]

I find the discussion of which company (AMD or Nvidia) supports linux better and how they do it as interesting as the next person, but lets stay on topic here. Were discussing the fglrx and what needs to be done to improve it.

I second that. Somehow the topic got completely lost.

Anyway, bridgman knows what's wrong now but i would like to know what's gonna happen now on the AMD side of this issue?
bridgman, feel free to respond

[liam]

The FOSS driver is not 100% optimized as has been explained and discussed over and over. Performance wise, I try to recall the figure but for e.g., 70% of the binary performance. For some, that is enough but not necessarily everyone.

I think if you are lacking features and performance, then one can be justified at considering options that allow for full performance and features.

The same features continue to be absent in the open source driver (look at the radeon feature matrix) and the performance is not fully optimized so obviously, it's not 100% open and the resources invested are lacking. It is just a matter of opinion whether you accept this caveat and can live with it.

Even though the proprietary driver is vilified here, if one buys a brand new card, they expect full features and performance, whatever the card can do. Unfortunately, the benchmark or comparative scale is via the latest Windows OS. But, these hardware companies are catering their editions to MS and the MS OS. Unless the open drivers are open to the point in which there is full openness to go from, there is always restrictions. So, it's based on tradeoffs?

Also, buying the AMD card, one is expected to bug track and troubleshoot if you want to contribute to the expanding improvement? It's a good idea but I am curious what time and expertise is needed... there is not as much investment from the company itself so you are expected to do a significant share.

Also, the improvement or progress of the FOSS driver is not motivated by money as much as the proprietary so there is a positive and negative benefit to that.

If they buy a video card and expect "full performance" then they should be using Windows, full stop. The only reason to want "full performance" from a graphics card (not compute card) is to play games and those just aren't nearly as well supported on Linux, full stop.
If you are using Linux then you shouldn't expect "full performance" from your gfx card. Stop whining. The situation is so much better now with open drivers than it ever was, and it is always improving. Have patience or use Windows (i.e., the only system that provides "full performance" with said gfx card).

Thanks airlied for the hard work, and bridgman for the patience.

[bridgman]

Anyway, bridgman knows what's wrong now but i would like to know what's gonna happen now on the AMD side of this issue? bridgman, feel free to respond

No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.

I guess I'll poke around in the bug tracker to see if there is a relevant ticket filed as well, if I feel up to wading through the insults and death threats.

[markg85]

No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.

I guess I'll poke around in the bug tracker to see if there is a relevant ticket filed as well, if I feel up to wading through the insults and death threats.

Which bug tracker? The amd one? Or the one that was linked to somewhere in this thread?

And could you please keep us up to date on the progress? I'm asking because I really want to use either opengl 2 or es in kwin simply because that is supposedly giving better performance on kwin..

Regards,
Mark

[smitty3268]

No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.

Well, sooner or later Red Hat will start using Gnome Shell. So I guess it just depends on whether you want to fix the drivers now and practice on KWin, or wait until the last minute to try and support it when you absolutely have to.

I know which one I'm betting on, given the history of fglrx.