Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

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

  • pingufunkybeat
    replied
    Originally posted by marek View Post
    As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.
    I agree that communication is important and desirable, but if the drivers crash, then surely something is wrong. Drivers should never crash, and this is what was happening with KWin 4.5, using advertised functionality. On all drivers, not just Intel, it was a Mesa bug.

    Regardless of whether it was reported correctly to the Mesa devs, or tested at the right time before releasing, which is a different issue.

    As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.
    But some people don't use modules. And DRI2 is only used by open drivers, as is exposing stuff through sysfs. Perhaps it's better than grepping the renderer string, but it's bound to be considerably more complicated and is also bound to change between driver versions, leading to complex logic.

    I don't know of a single, reliable way of detecting what the driver can actually accelerate reliably. Ideally, they would all accelerate everything reliably, but unfortunately this is not likely to be the case soon.

    Leave a comment:


  • marek
    replied
    Originally posted by pingufunkybeat View Post
    Marek, how would you test correctly if a driver provides appropriate functionality?

    It is known since the last KWin fiasco that you can't trust the advertised functionality,
    When some Kwin dev (maybe Martin again?) claimed that, no open driver developer knew about broken advertised functionality. We thought everything was alright, everything worked fine for us. Most games ran beautifully. The drivers do NOT claim to support things they do not support. As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.

    Moreover, the NVIDIA OpenGL implementation is far from being compliant, so if something works on NVIDIA, it pretty much means it might not work anywhere else. I *like* proprietary drivers, but relying solely on NVIDIA ones might lead to frustration as you can see in various Martin's blog posts. Unlike NVIDIA, both Catalyst and Mesa try to follow the OpenGL specification to the letter, even though the spec is sometimes self-contradictory or doesn't make sense.
    Further reading on the subject (a little bit more technical): http://www.g-truc.net/post-0348.html

    Originally posted by pingufunkybeat View Post
    and checking for direct rendering is also a hack which doesn't even work anymore. Blacklists caused their own set of problems, and if there is no check, KWin will crash all the time, like 4.5 did.

    What is the correct way to check this?
    The best way is to communicate and do the job right. Linux will never work if developers ignore each other. The Kwin devs should assume everything works and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.

    The worst scenarios are:
    - Reverting to an older version without telling anyone and hoping the problem will be fixed in the next version (it won't).
    - Blacklisting the software without telling anyone (again, it won't get fixed until either a developer runs into it or a user reports it). And don't forget to make a blog post about it to piss off everybody else.

    As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.

    Leave a comment:


  • pingufunkybeat
    replied
    P.S. It's still wrong to rely on the renderer string, and I still have no better solution for enabling basic functionality on software people expect to just work.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by locovaca View Post
    Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?
    Compiz and Mutter. And any other application which is used daily by tens of millions of people.

    I mean, if people expect KDE guys to test several dozen drivers (and I do), then I'd expect a driver dev to have a quick check whether he broke the second most widely used window manager under Linux.

    Leave a comment:


  • Temar
    replied
    Originally posted by locovaca View Post
    Why is it Intel's responsibility to test KDE's code out with their driver?
    Because there is no point in having a driver which does not work with widely used software. We are not talking about a random 3D application here but about one of the major Linux desktops. Testing their driver on the major Linux desktops is the least Intel can do.

    Leave a comment:


  • locovaca
    replied
    Originally posted by pingufunkybeat View Post
    But this time, it's not KDE who released a new version, it was Intel, and they didn't check if it works. Now KDE is facing the possibility that compositing will be broken on Ubuntu for the next 6 months.
    Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by allquixotic View Post
    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.
    That's what KWin did, and the drivers crashed every time you changed a setting, or enabled some of the effects. Randomly.

    Even if you did a runtime check to see if the advertised things actually work, the drivers crashed.

    That's why they implemented the whitelists. Without whitelists, nothing would work.

    I do agree that working with the driver developers is what should be done, and that the drivers should be debugged and fixed whenever something like this is detected.

    But this time, it's not KDE who released a new version, it was Intel, and they didn't check if it works. Now KDE is facing the possibility that compositing will be broken on Ubuntu for the next 6 months.

    Leave a comment:


  • pingufunkybeat
    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.
    That's because most people don't know what's crashing.

    Leave a comment:


  • Goderic
    replied
    @allquixotic
    IIRC KWin devs used to do this, but the free drivers claim to support things they don't support. So you can't really blame them...

    Leave a comment:


  • agd5f
    replied
    The renderer string changes have some purpose behind them, it's not done just to be malicious. For example, in the radeon 3D drivers, we used to just report the driver name (radeon, r300, r300, r600) but not the specific asic. Wine wanted more granular information (rv350, r520, r430, etc.) so we added it to the renderer string. Why not file bugs or talk to the developers when something doesn't work rather than relying on a random sting and not telling the driver developers.

    Leave a comment:

Working...
X