Announcement

Collapse
No announcement yet.

KWin May Drop Support For Catalyst, Vintage GPUs

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by hal2k1 View Post
    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.

    Comment


    • Originally posted by RealNC View Post
      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...

      Comment


      • Originally posted by hal2k1 View Post
        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).

        Comment


        • Originally posted by Ansla View Post
          That's not really the same thing as supporting OpenGL ES contexts.
          The fglrx Support an real ES Implementation.

          Originally posted by Ansla View Post
          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...
          Its simpler and the khronos group has Conformance tests for opengl es

          Comment

          Working...
          X