Announcement

Collapse
No announcement yet.

Open-Source GPU Drivers Causing Headaches In KDE 4.5

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

  • #41
    Originally posted by smitty3268 View Post
    The current attitude seems to be, well, it works on my nvidia machine, and no one else stepped up to fix it.

    This is disappointing, but perhaps not unexpected. i've seen this kind of attitude from certain kde developers before And i'm a kde user myself, so i'm not just bashing here.
    There is a reason for this. As i said earlier in this thread, KDE's true reason of existance has always been to showcase Qt toolkit.

    There is nothing wrong with that of course.

    But this is the primary reason KDE devs have this mentality, their software is meant to impress, not to be extensively used. They want to prove what qt can do, so they add new features constantly without caring much if the existing ones are stable enough.

    That is where works for me(tm) attitude comes from. When you design something to showcase a technolodgy, what is important to you is for the technolodgy to work on your demo machine. You don't really care if it can be used on other machines, that is not your target.

    I really like KDE, that is why i decided to keep it installed on my Arch machines even though i default to GNOME. But all these years they really fail to make me use their desktop for more than a toy...

    Comment


    • #42
      Originally posted by TemplarGR View Post
      There is a reason for this. As i said earlier in this thread, KDE's true reason of existance has always been to showcase Qt toolkit.
      Obviously the dozens of independent developers who love opensource and KDE waste their time just for the glory of Nokia... "sighs"

      Comment


      • #43
        Originally posted by Apopas View Post
        Obviously the dozens of independent developers who love opensource and KDE waste their time just for the glory of Nokia... "sighs"
        I am not talking about peripheral apps here, i am talking about the core KDE project. This is made by Trolltech employees, not independent developers. Try contributing to core KDE and you will soon find out what is happening...

        Comment


        • #44
          Actually I've tired KDE 4.5.1 KWin on F14 aplha with awhide mesa bits (I believe LGLSL2 is main difference here) and it worked fine, including blur effect on Radeon X300 mobile.
          Blur introduced some slowdown but performace while not stellar was stil acceptable. Given that X300 mobiles are no speed daemons and oss radeon drivers stilllack some features like page-flip i'd say results were quite good.

          As far as using OGL 2.x vs 3.x I'd say for next year 2.x seems to be better idea. First because there's lots of hardware that is ~2.x capable but not really 3.x (i mean all the r300-500 chips, NVidia GF5x00-6x00 and intel chips), another thing is that in '11 most of the hardware should have decent OGL2.x capable driver, be it proprietary NVidia, FGLRX, radeong or r600g.

          BTW I've read this blog post and there's nothing about Radeons, most of the complaints were about intel driver, so there's no need for radeon devs to be so defensive
          But still there could be a bit better communication between kwin and drivers devs.

          Comment


          • #45
            Originally posted by Xeno View Post
            BTW I've read this blog post and there's nothing about Radeons, most of the complaints were about intel driver, so there's no need for radeon devs to be so defensive
            But still there could be a bit better communication between kwin and drivers devs.
            More than 90% of the Mesa code is common between intel, radeon and nouveau, and that goes up even higher with Gallium3D. There's a reason they all have roughly the same level of GL support, albeit with varying degrees of polish.

            IMO complaining about the intel driver makes even less sense than complaining about radeon -- the intel devs do a remarkably good job exposing a decent level of functionality on their hardware, including things like software implementation of vertex processing when the hardware doesn't support it. Implementing vertex processing on the CPU may cause some unexpected performance problems for the app but it frequently works well and the alternative is to cap OpenGL support at a *very* low level.

            Again, I don't have a problem with the original blog post, it was more of a "hey the problem is bigger than you think, it's not all our fault" discussion than a "hey the drivers suck and it's all their fault" rant, but it does expose a fundamental mismatch between the level of implementation expected by KDE developers and what is likely to be available in the near future and suggests that "assuming a high level then blacklisting the exceptions" may not be a workable strategy right now, at least for another 6 months or so. Fixing this is going to take cooperation and collaboration, and in the meantime "don't be hating on anyone" is probably the best strategy.
            Test signature

            Comment


            • #46
              Originally posted by TemplarGR View Post
              There is a reason for this. As i said earlier in this thread, KDE's true reason of existance has always been to showcase Qt toolkit.
              Sorry, but you are way off with this statement. A big majority of KDE developers are not employed by Nokia at all and their aim is not to write demos of Qt. If that was so the entire school system of Brasil and schools in Portugal and the French parliamentand many others wouldn't use KDE desktops for production use. KDE developers also uncover bugs in Qt (just like they do with graphics drivers and graphical stack in general) and some of them also don't get fixed by Qt developers for quite some time. And the same goes if you are talkign about core or not core KDE software. So please stop spreading this misconception.

              As I understand with al this talk is that there are two main problems:
              * Communication between KDE and Xorg/Mesa community
              * Big lack of developers working on Xorg/Mesa

              I'm not sure what to do about the first problem, This is something KWin/Plasma developers and Xorg/Mesa developers have to solve among themselves. One part should start contacting with the other and I'd says those who see the problem, KDE devs here, should be the first to reach out to the other side.

              As for the second problem, Well Xorg and Mesaa projects should really pro-actively do something in the direction of attracting new young developers. GSoC is nice, and some more programs like this would probably help. And when there is no such program there should be a good documentation for beginners trying to get into Xorg/Mesa coding, Currently there is a big lack of this, as i've probably said many times here, and this has a great impact on attracting new people to become Xorg/Mesa developers.

              In any case the focus should be on identifying problems and weaknesess in the infrastructure and trying to find a solution to these problems, not pointing fingers around.

              Comment


              • #47
                Originally posted by aaaantoine View Post
                What about AMD?

                Ever since I upgraded to KDE 4.5 my display flickers when switching windows when Compositing mode is enabled.
                Are you using dynamic power-management?! If yes, that might be your Problem.

                Comment


                • #48
                  Originally posted by Xeno View Post
                  As far as using OGL 2.x vs 3.x I'd say for next year 2.x seems to be better idea. First because there's lots of hardware that is ~2.x capable but not really 3.x (i mean all the r300-500 chips, NVidia GF5x00-6x00 and intel chips), another thing is that in '11 most of the hardware should have decent OGL2.x capable driver, be it proprietary NVidia, FGLRX, radeong or r600g.
                  It's probably worth mentioning that the r300-500 families were all designed before the GL 2.0 standard came out, so it's only "luck and attempts to align the standard with the available hardware" that allow them to even partially run GL 2.0 or higher. Same applies for all of the other hardware from that time period.

                  Unless we can assume that in 2011 all of the pre-r600 hardware will disappear (which seems unlikely given all the work being done on the r300-r500 drivers) the only safe standard for the next couple of years is going to be a carefully chosen subset of GL 2.x, worked out in conjunction with the xorg community (eg "hey, we can pretty much get by with what works on the drivers today but we really need function XYZ to be reliable when used this way, can you folks do something about that specific functionality ?".

                  Recent Wine development efforts offer a good model for how this can work -- their initial development was done almost entirely on a single hardware/driver combination (NVidia proprietary) and the resulting software didn't work well on pretty much anything else, but over the last couple of years the Wine devs have been submitting really good problem reports ("hey, when I call function X in this way on this hardware Y and distro Z I expect to get ABC but I actually get DEF"), giving the driver devs a decent chance of finding and fixing the problem, and have recently been submitting fixes to the open source drivers directly. In other cases, driver devs have responded along the lines of "hey, that's not a valid OpenGL sequence although I understand it works on your system, if you replace it with <new sequence> then it should work on most platforms". Communication. Between all of these actions the result has been a fairly significant improvement in the degree of Wine support enjoyed by users.

                  Originally posted by Tsiolkovsky View Post
                  As for the second problem, Well Xorg and Mesaa projects should really pro-actively do something in the direction of attracting new young developers. GSoC is nice, and some more programs like this would probably help. And when there is no such program there should be a good documentation for beginners trying to get into Xorg/Mesa coding, Currently there is a big lack of this, as i've probably said many times here, and this has a great impact on attracting new people to become Xorg/Mesa developers.
                  Investing in documentation of the current stack while that stack is undergoing a major rewrite is generally not a good use of time, since whatever you write today will be obsolete by the time a new developer has worked their way through it. There is work being done by the xorg community on documenting the "end state" (ie the portions of the stack that will be active 6 months from now) and that work should help to reduce the entry barrier in future.

                  That said, experience to date suggests that writing graphics hardware drivers today requires a sufficiently unusual combination of skills (understanding the internals of complex hardware *and* being able to help drive the refactoring of million-line software stacks) that even really good documentation is not likely to bring in more than a couple of additional devs. You can't make the current stack "accessible" no matter how much you document it.

                  A bigger improvement is going to come from making the stack more modular and more maintainable (some of that "wasted effort" everyone loves to talks about). The big deal with Gallium3D is that it compacts the nasty hardware-specific portions of the driver into a smaller part of the code, with a cleaner and more consistent interface to the rest of the Mesa stack. Even that is not likely to bring in a lot more developers (programming modern graphics hardware still requires an unusual combination of skills), but it will ensure that the few people who *do* have the right interests and skills are not likely to be driven away by the complexity of the stack before fully engaging.
                  Test signature

                  Comment


                  • #49
                    Originally posted by bridgman View Post
                    It's probably worth mentioning that the r300-500 families were all designed before the GL 2.0 standard came out, ...
                    That's why i put ~2.x , also I know about change in relation between wine - mesa devs, I do read #radeon log too.
                    We can agree the situation with kwin is somehow similar to wine, that would be great if kwin devs would work with mesa devs the samy way wine devs do.

                    Maybe someone would point mr Gr??lin to your post as an example how those issues could be solved.
                    All in all someone needs to make the move first for the thigs start to happen.

                    Comment


                    • #50
                      Originally posted by TemplarGR View Post
                      I believe kwin devs are funded more than gnome's, indirectly. KDE is mostly being developed by Nokia employees, and they develop KDE in order to showcase their Qt toolkit...
                      This is the most incorrect thing I've ever seen on Phoronix.

                      Please don't post such unfounded nonsense anymore.

                      Comment

                      Working...
                      X