Page 7 of 8 FirstFirst ... 5678 LastLast
Results 61 to 70 of 75

Thread: Martin Takes His Mesa Issues To The List

  1. #61
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    Quote Originally Posted by RagingDragon View Post
    I was using xf86-video-ati and KDE together for a year or two without incident. My main problem with the open source drivers is lack of game support
    I think that pretty much all the native Linux games work with OSS radeon drivers. There are only very few exceptions, and I can't think of many. Trine has messed up lighting, but this will be fixed in git soon, and I can't think of any others. Oil Rush, when it's released, maybe.

    The major issue for existing games is performance, but most things are playable.

  2. #62
    Join Date
    Dec 2010
    Posts
    1,177

    Default

    Quote Originally Posted by MPF View Post
    Trying to hide bugs never works.

    I don't know for intel or radeon, but clearly, nouveau is not even polished-enough to accept crashes report (only mis-rendering bug reports are accepted).
    I find your comment amusing. First you don't want to hide bugs but then you don't even accept bug reports for anything but cosmetic glitches.

    Here's an idea: Fix your bugs and don't just leave them unhidden, rejecting every incoming bug report that's not about a cosmetic issue.

    Quote Originally Posted by MPF View Post
    People can't expect things to work flawlessly when a driver is experimental.
    That's bull.
    Red Hat releases Nouveau as part of every Fedora release since quite some time (and it's also part of RHEL 6). And Red Hat has AFAIK one Nouveau developer as employee.
    That means: Every 6 months there is an actual Nouveau release that has to be release quality and the RH guy in your team is the one who has the responsibility to achieve it.

    Quote Originally Posted by smitty3268 View Post
    I think they did say - it's whatever projects they are actually being paid to support. I'm certain there are some Red Hat or other devs being paid to make sure that Gnome Shell or Compiz are working. Apparently none of the distros have ponied up to make any developer responsible for KWin support.
    Novell used to have Lubos Lunak as KWin maintainer but Novell assigned him away from KDE to work on LibreOffice instead.

    Quote Originally Posted by bridgman View Post
    it just seems that relatively more of the developers working on the drivers use gnome than use kde.
    What a nice little excuse you have there wasn't there the fact that the core developers of the Radeon and Intel drivers are employed by AMD/Intel to work on the drivers. So do your work you guys are paid for by our purchases of your hardware products!
    An occasional 'kwin --replace' is the very least you high-paid developers can do once in a while!
    It's absolutely embarrassing that in a later comment you blame the distributors for your bugs!

    Quote Originally Posted by pingufunkybeat View Post
    I expect the distributions to make sure that the software they ship works correctly, and I don't know how they managed to get the intel update in without noticing that KWin won't run compositing with it.
    Just because some distributors also fucked up (Red Hat's KDE team members mostly work part-time on KDE stuff while Canonical made all two paid Kubuntu members work on Unity 2D because of their Qt skills), doesn't mean that the overall fault does not lie with the driver developers. Changing an ID string in a minor, bug-fix release is not something that is tolerable. Next major version: Fine. Minor release: No way!
    Every somewhat professional software implements string freezes for minor versions for good reasons.

    Quote Originally Posted by deanjo View Post
    Feel free to visit the openSUSE KDE room, lots of paid devs there all the time fixing all kinds of KDE issues (actually seems to see a lot more activity then the Gnome channel).
    Priorities of Novell lie with GNOME nonetheless. GNOME is the default for SUSE Linux Enterprise Desktop with Plasma Desktop rather hidden (no clear desktop selection screen as with openSUSE's DVD). Banshee, F-Spot, Evolution, and MonoDevelop are just four examples of full-blown GNOME applications written by Novell whereas in KDE software the contributions are limited to bugfixes and integration work.

  3. #63
    Join Date
    Sep 2008
    Posts
    34

    Default

    Quote Originally Posted by pingufunkybeat View Post
    I think that pretty much all the native Linux games work with OSS radeon drivers. There are only very few exceptions, and I can't think of many. Trine has messed up lighting, but this will be fixed in git soon, and I can't think of any others. Oil Rush, when it's released, maybe.

    The major issue for existing games is performance, but most things are playable.
    Has anyone gotten: UT2004, Doom 3, Quake 4 and/or Quake Wars working with recent open source AMD drivers? I haven't been able to find any reports one way or the other.

    Uniengine uses features that aren't supported by Mesa (i.e. tesselation), so even if they get Oil Rush running on the open source drivers alot of the graphics features would have to disabled when doing so. Since my hardware supports those features, and they work with proprietary drivers, this makes the open source drivers alot less than appealing.

    If/when steam comes to Linux, we can be certain it'll work with the proprietary drivers. But will it work with the open source drivers? Considering that the open source drivers are effectively limited to OpenGL 1.x, with buggy OpenGL 2.x support, incomplete OpenGl 3.x support and no OpenGl 4.x support, I have my doubts.

  4. #64
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    Quote Originally Posted by RagingDragon View Post
    Has anyone gotten: UT2004, Doom 3, Quake 4 and/or Quake Wars working with recent open source AMD drivers? I haven't been able to find any reports one way or the other.
    I finished Doom3 more than a year ago.

    I've played Doom3, Quake4 and Prey recently, with no problems (everything renders correctly, and is fast enough).

    I haven't tested ET:QW and UT 2004, but they're reported to work: http://wiki.x.org/wiki/RadeonProgram. Keep in mind that many of the reports there are outdated, and would be platinum with more recent drivers.

    The last missing piece of the puzzle was s3tc for recent hardware.

    Uniengine uses features that aren't supported by Mesa (i.e. tesselation), so even if they get Oil Rush running on the open source drivers alot of the graphics features would have to disabled when doing so. Since my hardware supports those features, and they work with proprietary drivers, this makes the open source drivers alot less than appealing.
    Oil Rush is the first OpenGL 3+ game coming out for Linux (AFAIK). When these become commonplace, you are right, OSS drivers will have problems. There's work going into OpenGL 3+ features, but it will take a while.

    But with most currently available games, they work fine.

    If/when steam comes to Linux, we can be certain it'll work with the proprietary drivers.
    You mean the Source engine, not Steam. Source engine is OpenGL 2. id's Rage is also OpenGL 2.

    But will it work with the open source drivers? Considering that the open source drivers are effectively limited to OpenGL 1.x, with buggy OpenGL 2.x support, incomplete OpenGl 3.x support and no OpenGl 4.x support, I have my doubts.
    OSS drivers support OpenGL 2.1 fully, with more than half of OpenGL3 extensions being supported.

    They were limited to OpenGL 1.5 2 years ago.

  5. #65

    Default

    Quote Originally Posted by deanjo View Post
    Feel free to visit the openSUSE KDE room, lots of paid devs there all the time fixing all kinds of KDE issues (actually seems to see a lot more activity then the Gnome channel).
    It's good to hear this. I supposed mainly OpenSuse volunteers interests about KDE, but it seems it's not true.

  6. #66

    Default

    Quote Originally Posted by RagingDragon View Post
    I was using xf86-video-ati and KDE together for a year or two without incident. My main problem with the open source drivers is lack of game support (and I believe this mostly due to upstream mesa limitations, not the drivers themselves). That, combined with the difficulties in running the AMD/ATI proprietary driver on non-Ubuntu distros, make an Nvidia GPU plus their proprietary driver the only viable alternative for me.
    For me OS drivers were also nearly painless till I have switched to Kubuntu 11.04beta2. It seems mesa and kwin packaged in the newest Kubuntu doesn't play good. There's few issues and I hope they will be fixed somehow.

  7. #67
    Join Date
    Dec 2010
    Posts
    108

    Default

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

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

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

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

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

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

  8. #68
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

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

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

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

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

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

  9. #69
    Join Date
    Dec 2010
    Posts
    108

    Default

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

  10. #70
    Join Date
    Dec 2010
    Posts
    108

    Default

    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

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
  •