Page 8 of 18 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 174

Thread: Open-Source GPU Drivers Causing Headaches In KDE 4.5

  1. #71
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

  2. #72
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    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.

  3. #73
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Quote 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

  4. #74
    Join Date
    Jan 2009
    Posts
    608

    Default

    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!"

  5. #75
    Join Date
    Feb 2007
    Location
    South Finland
    Posts
    32

    Default

    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

  6. #76
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

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

  7. #77
    Join Date
    Oct 2009
    Posts
    111

    Default

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

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

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

  8. #78
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

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

  9. #79
    Join Date
    Jan 2009
    Posts
    1,296

    Default

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

  10. #80

    Default

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

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
  •