Page 11 of 11 FirstFirst ... 91011
Results 101 to 109 of 109

Thread: KWin May Drop Support For Catalyst, Vintage GPUs

  1. #101
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    765

    Default

    Quote 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?
    In his blog some one ask this. his answer was "there is no runtime switch for GLES."

  2. #102
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    What's a "runtime switch"?

  3. #103
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    765

    Default

    Quote Originally Posted by RealNC View Post
    What's a "runtime switch"?
    I think we have to wait until he responds

  4. #104
    Join Date
    Mar 2010
    Posts
    158

    Default

    Quote Originally Posted by Nille View Post
    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.

  5. #105
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    765

    Default

    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.

  6. #106
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote 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.

  7. #107
    Join Date
    Oct 2010
    Posts
    352

    Default

    Quote 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...

  8. #108
    Join Date
    Oct 2010
    Posts
    352

    Default

    Quote 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).

  9. #109
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    765

    Default

    Quote 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.

    Quote 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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •