Announcement

Collapse
No announcement yet.

Martin Takes His Mesa Issues To The List

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

  • phoronix
    started a topic Martin Takes His Mesa Issues To The List

    Martin Takes His Mesa Issues To The List

    Phoronix: Martin Takes His Mesa Issues To The List

    Over the weekend there was a rant by Martin Gr??lin, the lead developer of the KWin compositing window manager for KDE, about Intel's open-source driver breaking. This is the second time in recent times that the driver has outright failed with KDE, which threatens the Intel KWin support in Ubuntu 11.04, but this time it's over the OpenGL renderer string being changed and KWin using that to determine direct rendering support. Martin has now written a very lengthy e-mail to the developers of Mesa...

    http://www.phoronix.com/vr.php?view=OTM1NQ

  • pingufunkybeat
    replied
    Originally posted by curaga View Post
    Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P
    OMG, that is awesome!

    Leave a comment:


  • RealNC
    replied
    Wow. Wall of Text. I'd be surprised if any of the devs will even try to read that.

    Leave a comment:


  • DanL
    replied
    Originally posted by curaga View Post
    Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P
    Awesome! Maybe I should hope to find some video acceleration under my Christmas tree?

    Leave a comment:


  • curaga
    replied
    Santa? In the last few days pepp has gotten r600g doing hyperz. Should arrive much sooner than xmas :P

    Leave a comment:


  • DanL
    replied
    Originally posted by mgraesslin View Post
    Oh and btw the Debian Easter Bunny gave me a present:
    Debian Easter bunny? Yes! I hope mesa Santa brings more r600g goodness (hyperZ, etc.)

    Leave a comment:


  • mgraesslin
    replied
    Oh and btw the Debian Easter Bunny gave me a present:
    Code:
    OpenGL vendor string:                   X.Org
    OpenGL renderer string:                 Gallium 0.4 on AMD RV710
    OpenGL version string:                  OpenGL ES 2.0 Mesa 7.10
    OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
    Driver:                                 R600G
    GPU class:                              R700
    OpenGL version:                         2.0
    GLSL version:                           1.0.16
    Mesa version:                           7.10
    X server version:                       1.9.5
    Linux kernel version:                   2.6.38
    Direct rendering:                       yes
    Requires strict binding:                yes
    GLSL shaders:                           yes
    Texture NPOT support:                   yes
    kwin(17037) KWin::Workspace::setupCompositing: Initializing OpenGL compositing

    Leave a comment:


  • mgraesslin
    replied
    Originally posted by bridgman View Post
    OK, maybe a dumb question but if the blacklist was removed some weeks ago and the recent mesa change broke a whitelist did the whitelist replace the blacklist ?
    The whitelist which broke is for enabling direct rendering. The blacklist was for disabling features which broke on some driver/hardware combo.

    Leave a comment:


  • bridgman
    replied
    Originally posted by mgraesslin View Post
    I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

    The problem was that the discussion started as blog posts, which then triggered posts on other blogs, and spread around the internet that way (there were some third- and fourth-order discussions going on). The responses mostly followed the blog posts, unfortunately.

    Originally posted by mgraesslin View Post
    The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.
    I didn't actually see "lack of understanding" as much as "unfortunate timing".

    Originally posted by mgraesslin View Post
    No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

    User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

    We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)
    The discussion at the time suggested that only one driver was really considered working (NVidia proprietary) which would make the whitelist pretty simple. If there was a much larger list of working drivers then I agree that would make a whitelist more difficult, but that was not the messaging at the time (it was more along the lines of "the NVidia proprietary driver works and the OpenGL 2.x standards have been out for years so if it's not working on your drivers you guys must all be stupid ).

    Originally posted by mgraesslin View Post
    I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

    Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.
    Seems reasonable.

    Originally posted by mgraesslin View Post
    As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.
    OK, maybe a dumb question but if the blacklist was removed some weeks ago and the recent mesa change broke a whitelist did the whitelist replace the blacklist ?

    Leave a comment:


  • mgraesslin
    replied
    Originally posted by bridgman View Post
    There were a lot of options discussed - it's hard to believe that none of them were feasible :
    I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

    The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.

    No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

    First lets have a short look at the time frame:
    • April 26th: Soft Feature Freeze for 4.5
    • May 11th: Hard Feature Freeze and Soft Message Freeze
    • May 26th: Release Beta 1
    • June 9th: Release Beta 2
    • June 17th: Mesa 7.8.2 BOOM - KWin starts to break
    • June 22nd: Hard Message Freeze
    • June 23rd: RC1 release


    At the time we noticed we had severe problems with Mesa 7.8.2 our release was basically done. For us it is important to provide users the best possible user experience and to not release a broken release. This implies to workaround issues in drivers rather than to wait for fixes. Our users don't care whether it's the driver or the desktop which is broken. Our users want a working desktop.

    Originally posted by bridgman View Post
    - use the GL 1.5-ish code paths by default (which worked on all drivers) and make GL 2.x code paths a user option
    User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

    Originally posted by bridgman View Post
    - use a (DX9-ish) subset of GL 2.x which could be supported on all of the hardware where that level of support was exposed
    All our code scales down. We added better checks to 4.6 - for 4.5 it was too late due to feature freeze.

    Originally posted by bridgman View Post
    - use a small set of functional tests rather than blacklisting, discussed with driver devs to use what "should work", driver devs would prioritize anything that crashed those tests
    Again: feature freeze. As a side remark, KWin had had one functional test in it's code base which started to break with Mesa in 4.5. Considering that we are not so interested in functional tests any more ;-) I am not fond at all of feature tests as that will delay the overall startup of the KDE Plasma Workspaces.

    Originally posted by bridgman View Post
    - work with the driver devs to identify a set of extensions/levels which could be used to identify drivers that would work well with KWin
    This would of course have helped for 4.6, but not for 4.5. I hope I explained in my mail that at that time I was very time constrained and our priority was making KWin work with the current driver and not the next driver.

    Originally posted by bridgman View Post
    - in the worst case, whitelist for GL 2.x code paths rather than blacklist
    We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)

    I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

    Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.

    As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.

    Leave a comment:

Working...
X