KWin May Drop Support For Catalyst, Vintage GPUs

[RealNC]

One thing I don't get with KWin, is why I can't run the OpenGL ES version of it on the binary drivers (NVidia *and* ATI). AFAIK, OpenGL ES is part of OpenGL 4.2 now, and both drivers support that version. So it should be possible to run the ES version using fglrx or nvidia.

Why isn't that possible?

[Nille]

Sigh! Power saving is fully supported by the open source Radeon drivers.

No its not. You can ask every laptop user.

[Nille]

One thing I don't get with KWin, is why I can't run the OpenGL ES version of it on the binary drivers (NVidia *and* ATI). AFAIK, OpenGL ES is part of OpenGL 4.2 now, and both drivers support that version. So it should be possible to run the ES version using fglrx or nvidia.

Why isn't that possible?

In his blog some one ask this. his answer was "there is no runtime switch for GLES."

[RealNC]

What's a "runtime switch"?

[Nille]

What's a "runtime switch"?

I think we have to wait until he responds

[hal2k1]

No its not. You can ask every laptop user.

Yes it is. Many laptop users may be running older code. Their doing so does not mean that the Radeon open source driver does not fully support power saving, because it does. Period.

http://www.x.org/wiki/RadeonFeature#...gement_Options

Plain, straightforward fact.

[Nille]

No its not done! and the most laptop user run most times lastest code only for the hope its better now. the currect "dynamic" Profile is not on by default. its not working with multihead and the display flicker at each clock changes.
then the driver use the low profile only if dpms is off.

[bug77]

Sigh! Power saving is fully supported by the open source Radeon drivers. In January this year, the OpenGL 3.0 milestone was reached, and Mesa 8 was released. Following that, (not yet released, but it is in the development branch), a significant performance improvement in the form of 2D colour tiling has landed. Whilst still in pre-release development, the next version of Mesa (version 8.1) is already showing between 12% and 30% performance improvement over the current release from just this one optimisation.

http://www.phoronix.com/scan.php?pag...tem&px=MTA2MTA

Other performance improvements such as HyperZ, enabling PCI-E 2.0, and other changes are in the piplline. The performance gap between the open source drivers and fglrx is rapidly closing.

The gap which is NOT closing is the one where the closed source fglrx is a closed proprietary binary blob, unstable and prone to regressions, adapted from the Windows blob so not suited to or integrated properly with the Linux stack, not fixable (supportable) by the Linux community itself, can't be distributed with Linux distributions, breaks every time there is a kernel update, and won't support KMS (and so may require awkward manual configuration) or Wayland.

That's nice, but a proprietary driver gives me all that from day 1. I was only arguing that proprietary drivers do not suck.

[Ansla]

One thing I don't get with KWin, is why I can't run the OpenGL ES version of it on the binary drivers (NVidia *and* ATI). AFAIK, OpenGL ES is part of OpenGL 4.2 now, and both drivers support that version. So it should be possible to run the ES version using fglrx or nvidia.

Why isn't that possible?

Are you talking about the GL_ARB_ES2_compatibility extension? That's not really the same thing as supporting OpenGL ES contexts. And even if it were possible to create an OpenGL ES context with the binary drivers, what makes you think OpenGL ES is not as broken as the regular OpenGL? Since it's even less used on the desktop chances are it's even more broken...

[Ansla]

Yes it is. Many laptop users may be running older code. Their doing so does not mean that the Radeon open source driver does not fully support power saving, because it does. Period.

http://www.x.org/wiki/RadeonFeature#...gement_Options

Plain, straightforward fact.

Will you give it a rest with claiming the radeon driver has reached feature-parity with fglrx? It's clear to anybody that there is still a large gap in both functionality and performance.

The fact you are pointing at is just that somebody marked power management as done on the wiki while it's still far from being useful. Like others said, dynpm is not yet enabled by default and when it is enabled it doesn't work very well. So I prefer to keep my E-450 on the high profile all the time. That still gives me ~3 hours battery life and it doesn't overheat either. While 3 hours is enough for me it wouldn't bother me at all if the battery lasted 5-6 hours that could be achieved in the optimal case (I think the producer claims 7-8 hours, but that's just "marketing figures", an euphemism for lies).