Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

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

  • allquixotic
    replied
    It's really a programming error in the application to expect the user to be running one of a finite set of whitelisted drivers. A perfectly viable, new driver could emerge tomorrow with all the needed ClosedGL support, and it wouldn't work only because you didn't recognize its version string? Bullshit.

    The problem with whitelisting is that, by taking on the problem of whitelisting, the application developer assumes de facto responsibility for going out into the world and discovering all the extant ClosedGL drivers that exist, and individually determining if each one is compatible with their program, and then adding them to the list if so. The timeliness of updating their list is a direct consequence of how agile their development cycle is, and how aware they are of alternative drivers. That a driver changed their version string is no different than the case of a completely new driver that the app developer isn't aware of: in both cases, it is the app developer's fault, because it became their responsibility to maintain the list from the moment they introduced whitelisting. An app developer who finds this deal to be intractable should reconsider the decision of using whitelisting in the first place.

    And the driver developers should be free to change their version string at will, too. No one ever intended the version string to be relied upon; you may as well rely upon the output of `cat /dev/random`. The problem is that the ClosedGL standard says nothing about how this string should be formatted, or what information it might contain, except that it must specify the core ClosedGL version that it supports. Look here:

    Originally posted by opengl.org
    OpenGL also provides a mechanism for detecting the OpenGL version at run time. An app may call glGetString(GL_VERSION), and parse the return string. The first part of the return string must be of the form [major-number].[minor-number], optionally followed by a release number or other vendor-specific information.
    So the app developer can either accept the onus onto themselves for fully understanding the remainder of the string past the core version number of all possible drivers, or they can simply rely upon other features of the GL API to determine if the driver has the features they want, and if so, use them.

    As to the complaints that swrast and llvmpipe advertise direct rendering and all the extensions and GL 2.1: my suggestion is to just not ship these drivers with distributions -- duh! If a user has a piece of hardware for which we have no driver, they'll get no GLX support at all, and glxinfo will say Direct Rendering: no. This is a pretty unambiguous indication that you ought not to try to enable compositing, and makes it REAL easy for other apps to figure out that they can't use GL.

    I don't know of any case where the software rasterizers are actually useful to end-users for real applications. First, if they have a video card that completely lacks hardware acceleration support, such hardware is very likely to be ancient, and so lack sufficient CPU power to make use of any software rasterizer, even llvmpipe. For the one in ten million installations that actually has sufficient CPU to use a software rasterizer to great effect, but no video card or no supported driver, they can use the package manager to grab the swrast or llvmpipe drivers after installation. For the one in a thousand (or one in a hundred) that has a fully working hardware accelerated driver that your whitelisting wouldn't have recognized, these users will have no problem if you disable whitelisting. (Aside: I know full well the utility of both developing and using the software rasterizers from a graphics developer's standpoint. I just think that this use case is sufficiently rare that asking them to install from the package manager is no high crime, especially since they're developers and are quite likely to compile from git anyway.)

    TL;DR? Okay Mr./Ms. impatient, here it is in plain terms: I have a proposal for fixing this mess. App developers: please don't do whitelisting based on any part of the version string except the first decimal number starting at index 0 of the string. Linux distributions: please don't ship the swrast or llvmpipe drivers by default in an installation, and make sure no package depends on them; make the user install them from your package manager.

    Leave a comment:


  • NeoBrain
    replied
    Originally posted by Nille View Post
    If the Driver Crash why not report it by the Driver Devs? I mean its not kwins fault if an Driver has problems with the EXT that he export.
    Yeah just reporting it and not workarounding it would probably mean that KWin would be unusuable on any hardware/driver combo but NV+blob. And I guess not even that would work perfectly...
    It wasn't just the intel driver which crashed, fyi.

    Leave a comment:


  • Milan
    replied
    As I see it, it happened to some Ubuntu beta release (users shouldn't complain with betas but they should fill bugs), KDE use hacks for feature detections, to parse a string is something to expect from Adobe.
    KDE tests are based only on NVidia binary drivers but they think Intel should test whether new release works with Ubuntu's KDE Natty beta release? Cmmon...
    And how do you think developers can improve drivers, I am sure there was a reason for that change. Issues like that should be solved with bug reports not with some blog and phoronix posts...

    Leave a comment:


  • Nille
    replied
    Originally posted by pingufunkybeat View Post
    People don't know that the drivers are responsible, they just see KDE crashing, and KWin gets the blame. Most users don't even have the debug symbols compiled in to be able to trace it to the drivers for a proper bug report.
    And now kwin try to blame the driver teams before they talk to them.

    Leave a comment:


  • Nille
    replied
    If the Driver Crash why not report it by the Driver Devs? I mean its not kwins fault if an Driver has problems with the EXT that he export.

    Leave a comment:


  • pingufunkybeat
    replied
    People don't know that the drivers are responsible, they just see KDE crashing, and KWin gets the blame. Most users don't even have the debug symbols compiled in to be able to trace it to the drivers for a proper bug report.

    Leave a comment:


  • mdias
    replied
    Originally posted by NeoBrain View Post
    KWin needs to know which effects can savely be enabled and which cause glitches or even crashes. You can check the OpenGL extensions to do that OR use feature tests. KWin used the latter ones previously, but apparently even the functionality tests caused crashes for some drivers. Thus, KWin now checks for the OGL render string and only enables per-driver and per-driver-version hardcoded feature sets. Which is kinda lame, but there's no other way to do it until the drivers get fixed properly (and are reliable enough to enable functionality checks again)..
    Understood, even though I agree that it's lame to do that... Intel users should just complain to their driver devs if their drivers don't work...

    Well, I can't complain that KDE people are worried about my experience, but I still think that's just wrong...

    Thank you for the info.

    Leave a comment:


  • NeoBrain
    replied
    Originally posted by mdias View Post
    Oh, sorry, I didn't know that since I don't use KDE.

    But then why do they check on the renderer string? To make extra sure? I don't get it, sorry, it's a genuine question.
    KWin needs to know which effects can savely be enabled and which cause glitches or even crashes. You can check the OpenGL extensions to do that OR use feature tests. KWin used the latter ones previously, but apparently even the functionality tests caused crashes for some drivers. Thus, KWin now checks for the OGL render string and only enables per-driver and per-driver-version hardcoded feature sets. Which is kinda lame, but there's no other way to do it until the drivers get fixed properly (and are reliable enough to enable functionality checks again)..

    Leave a comment:


  • mdias
    replied
    Originally posted by pingufunkybeat View Post
    It does that already. And disables compositing if it notices that it is too slow.
    Oh, sorry, I didn't know that since I don't use KDE.

    But then why do they check on the renderer string? To make extra sure? I don't get it, sorry, it's a genuine question.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by mdias View Post
    I believe the best way to handle this is to make the DE check the speed and availability of the needed operations on the active driver whenever it changes.
    It does that already. And disables compositing if it notices that it is too slow.

    Leave a comment:

Working...
X