Announcement

Collapse
No announcement yet.

Open-Source GPU Drivers Causing Headaches In KDE 4.5

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

  • #71
    Originally posted by TemplarGR View Post
    And Vincent is a KDE fanboi and writes nonsense as usual.
    Thanks for the constructive critisism; I totaly admire people that put lables on "Those are wrong and dumb" because they don't have what some people call "insight" and see this "cutting off by gaining the popular vote" the only remaining way to win a discusion. Congrats.

    Why does it matter to us that KDE runs on Windows or Macs? Are we supposed to care now? We are using Linux or BSD's for a reason. What's the point of using KDE on top of other platforms? If i wanted to use Windows, i wouldn't need KDE...
    I could of course explain to you what the benifits are, but I am kind of lacking the spark that would make me invest actual time to do so.

    In reality, the fact that KDE now is platform agnostic alienates it from the platforms it draws its strength from...
    I do feel the spark to correct things that are utterly wrong. For example: what amount of strenght do you think it will put back into Linux by being used on non-Linux patforms?
    "I like Kdenlive as it kicks Sony Vegas' ass!"
    -"Great; it comes from Linux"
    "Realy? I thought that-"
    -"Think again"

    If they keep going on like this, KDE will die. It will alienate Linux and BSD users, and Windows and Mac users WILL NEVER CARE ABOUT IT. It will simply become irrelevant...
    That's why there must be so much developer interest in KDE; because nobody cares about KDE.

    Comment


    • #72
      Yeah, Nokia seems to have one of these magic resource wands. They announce that they're gonna need more people working for them in the future and Finnish universities double their entrance limits in engineering faculties.

      Comment


      • #73
        Originally posted by bridgman View Post
        There are only three obvious solutions I can see :

        1. Reduce the level of driver functionality used/expected by KDE to a level that can be fairly reliably supported across the user base, ie somewhere in the GL 1.3 to GL 1.5 range with a couple of exclusions (eg gl_arb_multisample). This is unattractive because it increases the workload on the KDE developers, who like everyone else are trying to do wonderful things with limited resources (ref. Martin's comment about using shader assembler vs GLSL).

        2. Accept that for at least the next year KDE requirements are going to be "right on the hairy edge" of what the drivers support, and that only a careful collaborative effort is likely to succeed. Define a mutually agreed subset of GL 2.x functions (possibly with some GL 3/4 low hanging fruit), use only that subset (KDE) and try to keep that subset working (Xorg). This seems the most feasible, and could include a combination of KDE folks at X conference, X folks at KDE conference, online collaboration, adding KDE-specific tests to piglet etc...

        3. Wave the "magic resource wand" and suddenly have 10x-50x the development resources available for driver development, so that drivers can live up to the high ideals expected of them. This would be great but the entire open source community has been looking for that damn wand for at least a decade now with little success.
        I missed an option - implementing some kind of "application blacklisting" at a driver level. The idea would not be to refuse to run an app, but to limit the extensions exposed to that app in cases where the app had multiple code paths (eg arb_fp/vp vs glsl) and the code paths for the lower level API usage worked better than the code which took advantage of higher level API usage. This would still be a pain to maintain but probably less of a pain than having each app blacklist drivers.

        I have not discussed the technical feasibility of this with anyone but it might be worth considering. A simple first step might be to provide a runtime option to the drivers which limits the level of GL support exposed, allowing user/script/distros to control the functionality exposed to each app. This is obviously no different from using app-level options to enable/disable use of specific GL features, but not all apps have that capability.

        Anyways, unless someone has found the "magic resource wand" in the last hour let's replace option #3 with the above suggestion :

        1. Reduce the level of driver functionality used/expected by KDE to a level that can be fairly reliably supported across the user base, ie somewhere in the GL 1.3 to GL 1.5 range with a couple of exclusions (eg gl_arb_multisample). This is unattractive because it increases the workload on the KDE developers, who like everyone else are trying to do wonderful things with limited resources (ref. Martin's comment about using shader assembler vs GLSL).

        2. Accept that for at least the next year KDE requirements are going to be "right on the hairy edge" of what the drivers support, and that only a careful collaborative effort is likely to succeed. Define a mutually agreed subset of GL 2.x functions (possibly with some GL 3/4 low hanging fruit), use only that subset (KDE) and try to keep that subset working (Xorg). This seems the most feasible, and could include a combination of KDE folks at X conference, X folks at KDE conference, online collaboration, adding KDE-specific tests to piglet etc...

        3. Formalize the idea of apps being able to make use of different sets of GL functions, either via app options (the most common way today, and the degenerate case of what Vincent suggested) or via driver options (runtime or app "greylist") which limit the set of functionality exposed to a specific app.
        Again, the core problem here is that exposing "implemented but not perfect" extensions is *generally* the right thing for users because it allows them to successfully run many more apps. The problem is what to do about the downside of that approach, ie how to handle applications which have higher expectations for those extensions than the drivers are able to deliver today.

        I haven't complained about the one minute edit limit today, so consider it complained-about

        Comment


        • #74
          This OpenGL 3 madness is bullshit. Even in 2010, there are still D3D9 games with cutting-edge graphics, take Starcraft 2 as an example. It uses all the graphics techniques you would expect from a modern game, even though D3D9 is somewhere between GL1.5 and GL2.1 (based on what hardware you look at). If that game doesn't need more, neither does kwin or any other compositor. To maintain the highest level of compatibility, I would go GL1.5, using the CG Toolkit to compile my GLSL shaders to ARB assembly. Don't tell me kwin devs can't implement the Gaussian blur in the 64 ALU instruction limit. Using GL3 will perhaps make the devs look great, but it won't improve graphics or anything compared to what they can achieve with GL1.5. It seems to me to be like "hey look, I got GTX460 and I can use GL4 for no reason! cool, yeah!"

          Comment


          • #75
            Imho I like more supa dupa fast 2D like scrolling speed. Even my integrated Radeon HD 3200 loses to Intel X3100 in this competion. With HD 3200 Firefox and Chromium feels really bad to use, with X3100 it feels like I want to end using Windows 7. Scrolling feels smooth and totally loveable.

            And yes of course I'm using Arch Linux with testing branch

            Comment


            • #76
              Originally posted by marek View Post
              To maintain the highest level of compatibility, I would go GL1.5, using the CG Toolkit to compile my GLSL shaders to ARB assembly. Don't tell me kwin devs can't implement the Gaussian blur in the 64 ALU instruction limit.
              That sounds like a good compromise, and would avoid the need to venture "so close to the edge" in terms of driver functionality. Might be the best answer so far.

              Comment


              • #77
                Originally posted by MaestroMaus View Post
                KDE doesn't fully exist out of volunteers either. Not communicating = doing a sloppy job.
                Come one. How many paid devs work on KWin? Is it really bad comunication to use something that is reported as supported?
                Devs can't just start to go on every irc-channel/ml of libs they use and ask "is xy really supported when it says so?". What they would get wouldn't be that friendly ...

                Further when lookin how few time FOSS devs regularly have, no matter what project they work on.

                It is simply an unfortunate situation for everyone involed and a constant learning process with hopefully the right conlcusions drawn --> that would imo be to communicate with the corresponding community here as not everything works as expected.

                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...
                Nope. Show me all those Nokia employees. E.g. I haven't noticed David Faure is working for Nokia. And if you don't know who that is than don't write such stuff ...

                Originally posted by TemplarGR View Post
                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.
                Complete utter crap, don't even get me started!

                Comment


                • #78
                  Originally posted by mat69 View Post
                  Is it really bad comunication to use something that is reported as supported? Devs can't just start to go on every irc-channel/ml of libs they use and ask "is xy really supported when it says so?". What they would get wouldn't be that friendly...
                  When the functionality is known to have just been implemented and still be under development, communication and/or testing are the *only* ways to know if using something is safe. Saying "the standard has been out for 2 years so it should be implemented everywhere" is optimistic at best.

                  I agree that asking "so, feature X is exposed, does it really work or are you guys lying" wouldn't go over well but something more along the lines of "we would like to use feature X, I know you guys just exposed it and are still working on it but would it be safe for us to use if we are just doing Y with it ?" would probably be welcomed.

                  Comment


                  • #79
                    1. Originally posted by airlied View Post
                      So if we are to compare kwin with say something like gnome-shell as equals, granted the g-s developers are probably being funded to work on this more, but still I get regular reports from the g-s devs in RH on what drivers do and don't work and what features are slow and missing, and we try and target Fedora releases to make sure that the g-s bits work on the shipping drivers.
                    Originally posted by airlied View Post
                    The g-s guys understand the ecosystem they are working in, and work with it. The kwin guys seem to take 0 interest in working with a community. I've gotten driver patches from g-s guys, and never any contact from a kwin developer. Granted RH also would prefer that I make g-s work so it gets a higher priority than kwin or games.

                    The thing is if kwin wants to be a Linux desktop it needs to run on top of Linux, not some ideal of what Linux should be if we had 50 more developers writing graphics drivers. Its called reality and generally living in it makes for a better quality of product.
                    I know GS is encouraging people to try GS on as many platforms as possible. Part of this is performance, but I have to imagine that it is also partly due to a desire to actually verify that GS can run on many different platforms.
                    http://shell-perf.gnome.org/systems
                    The goal a is usable WM/environment that can be run on pretty much any hardware built since, IIRC, 2005, and that is also modern.
                    As others have said, I don't really see the point in only offering these effects that just don't work with so many open drivers.

                    Best/Liam

                    Comment


                    • #80
                      Originally posted by TemplarGR View Post
                      First of all, to all those who disagreed, i am sorry but Trolltech DOES lead KDE development. You may hate to admit it and that's ok, but that may be because you never bothered taking a look at KDE's contributors... I did. And they are mostly Trolltech in key positions.

                      Just because a brazilian wrote a plasma applet for example, doesn't mean that KDE is strongly affected by him. The direction it takes is mostly decided by Trolltech.
                      If there are many Trolltech contributors it seems they just simply care about KDE. Why don't you complain about Gnome contributors? Looking at Gnome it seems the direction it takes is mostly decided by ex-Ximians.

                      http://www.novell.com/linux/ximian.html

                      Now with the backing, endorsement and resources of Novell, key members of Ximian continue to play a central role in the open source community, providing leadership and core technology to key open source projects and industry groups, including GNOME, the Free Software Foundation, and the Mono Project, a community initiative to develop an open source, Linux-based version of the Microsoft.NET development platform.
                      And Vincent is a KDE fanboi and writes nonsense as usual.
                      It's you who's writing a nonsense here.

                      Why does it matter to us that KDE runs on Windows or Macs? Are we supposed to care now? We are using Linux or BSD's for a reason. What's the point of using KDE on top of other platforms? If i wanted to use Windows, i wouldn't need KDE...
                      Yes, it does matter. Windows has nothing interesting to offer except games and usually this is one of the most important reasons people use it. I know many people who love Amarok and they want to use it on Windows. There's much more interesting software in KDE. More users more feedback, more donations, better advertisement etc. How is it different using KDE on Windows, OS X then on BSD? They're in the same camp.

                      In reality, the fact that KDE now is platform agnostic alienates it from the platforms it draws its strength from... If they keep going on like this, KDE will die. It will alienate Linux and BSD users, and Windows and Mac users WILL NEVER CARE ABOUT IT. It will simply become irrelevant...
                      It will rather bring Windows and OS X users to Linux. Don't put Linux and BSD in the same camp, because they're not.

                      According to the main thread it seems it's strange drivers report features which aren't working properly or at all. If someone decides to write an app and then it doesn't work properly, he spends days or weeks at finding the problem, but then he discovers the problem is in drivers...

                      Comment

                      Working...
                      X