Page 12 of 18 FirstFirst ... 21011121314 ... LastLast
Results 111 to 120 of 174

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

  1. #111
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    Hellfire uses 4.4.5. Seems to be better suited for you.

  2. #112
    Join Date
    Mar 2009
    Posts
    141

    Default

    Quote Originally Posted by allquixotic
    So what is the heart of the issue? Are graphics drivers just so difficult a domain to understand that getting community contributions is difficult to impossible?
    Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch. I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.

    What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).

    Quote Originally Posted by brent
    I cringe everytime I see "freetards" making the bold statement that the open source drivers are great - they clearly aren't if you need anything more than basic 2D acceleration.
    They are more stable and better supported by distros. I've had way fewer issues with open source drivers than blobs. Open drivers are the only sane long-term solution.

  3. #113
    Join Date
    Aug 2007
    Location
    Poland
    Posts
    215

    Default

    Quote Originally Posted by smitty3268 View Post
    It seems to be mostly older Intel drivers causing issues. Does everything work with the current git master?

    The main reason they want to start using OpenGL2 is so they can port KWin to OpenGL ES and run on mobile devices. Sounds like FBOs are one of the main OpenGL3 features they'd like to use, but they will retain backwards compatible code for it. Other stuff like geometry shaders might be used in advanced effects only, or with alternative lower-quality backups in place.
    Is FBO supported on R300 devices?

  4. #114
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,516

    Default

    Quote Originally Posted by Smorg View Post
    Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch.
    Yep, although a few new developers do manage to jump in every year, which is impressive. The most important pre-requisites seem to be (a) understanding OpenGL, (b) enough of an interest in hardware to pick things up quickly via (c) quick learning & good communication skills in order to be able to interact well with the rest of the developers on IRC and "learn as you go".

    Quote Originally Posted by Smorg View Post
    I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.
    There are maybe a couple of dozen in total spread across all the HW brands. There is a *lot* of common code, particularly in Mesa. Remember that agd5f worked on the open source drivers for ~7 years before he came to work at AMD, and the same goes for a lot of the other devs. The guys working for AMD (or Intel) have access to internal information so there is a specific class of "make new HW run for the first time" work that only they can do, but most of the development effort is going into improving the drivers using already-available information.

    Quote Originally Posted by Smorg View Post
    What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).
    I don't understand this comment unless you are talking about r200-class hardware or are using the (relatively stagnant) "classic" mesa drivers -- 3 years ago there was almost no 3D support available on anything past r200, now there is fairly significant GL 2.x available on nearly all post-r200 hardware. Are you running the Gallium3d drivers (which are improving rapidly) or the classic drivers (which aren't changing much) ?

  5. #115
    Join Date
    Apr 2007
    Location
    Bulgaria
    Posts
    269

    Default

    OK, so who is going to fix the annoying kwin compositing flickerings and blur effect in the end?

  6. #116
    Join Date
    Sep 2010
    Location
    Portugal
    Posts
    4

    Post Gallium3D

    Hi everyone,

    i've registered myself so i can tell you about my experiences with gallium3d.

    I'm one of those guys that were hit by the recent slowdown and loss of desktop effects with the recent kde 4.5.1.
    I'm currently running ( as always do ) the testing branch of kubuntu Maverick. I work in linux as a living and have been lucky running development versions of kubuntu now, and slackware till recently.
    So after digging and reading this thread from the begining i decided to try gallium for the first time and all i can say is, man, you are doing a great job and for any of you who are having problems with kde 4.5.1 and like i, do have an old ATI radeon x700 or something similar and are running any *ubuntu version, give https://launchpad.net/~xorg-edgers/+archive/ppa a try. My desktop is running a bit faster and i've got my desktop effects back.

    Also, take a look at http://apachelog.wordpress.com/2010/...cs-system-kcm/ i've compliled mysef but it will be merged to kubuntu maverick, it is already at maverick changes mailing list. My desktop feels snapier with raster as qt graphics rendering.

    My specs
    helmer@zen-mobile:~/incoming/src$ glxinfo |grep -i opengl
    OpenGL vendor string: X.Org R300 Project
    OpenGL renderer string: Gallium 0.4 on RV410
    OpenGL version string: 2.1 Mesa 7.9-devel
    OpenGL shading language version string: 1.20
    OpenGL extensions:

    helmer@zen-mobile:~/incoming/src$ lspci |grep -i vga
    01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE)

    System Information
    Manufacturer: Acer, inc.
    Product Name: Aspire 1690
    Version: Not Applicable

    BIOS Information
    Vendor: Acer
    Version: 3A45
    Release Date: 04/21/06
    Address: 0xE79A0

    Thank you all.

  7. #117
    Join Date
    Oct 2008
    Posts
    3,181

    Default

    Quote Originally Posted by Jimbo View Post
    No, doesnt' work. I already tried. Opengl composite is totally disabled, at least on kde 4.5.1 ubuntu maverick. And it was working superb! on 4.4 once u disabled blur.

    The solution seems pretty simple to me, disable blur on intel integrated drivers, and TA-DA ! it works, but KDE only test on nvidia hardware, pfff.
    You can edit the blacklist manually if you want. See http://blog.martin-graesslin.com/blo...-kwin-effects/ for details.

    It uses KWinís default KConfig file (~/.kde[4]+/share/config/kwinrc) and uses KConfigGroup "[Blacklist]". The blur effect uses the sub-group "[Blur]", while the Lanczos filter uses the sub-group "[Lanczos]"

  8. #118
    Join Date
    Jun 2010
    Posts
    219

    Default

    Quote Originally Posted by Smorg View Post
    Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch. I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.
    There is lots of work being done to reduce the complexity of this development all the way from the kernel down to the X Server. Legacy code will always be a mess.

    Quote Originally Posted by Smorg View Post
    What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).
    You can only get the real information by looking at the actual commits and any associated notes with them. You can't honestly think that nothing of value is being done?

    Quote Originally Posted by Smorg View Post
    They are more stable and better supported by distros. I've had way fewer issues with open source drivers than blobs.
    Man, this argument, I am tired of hearing. I have the exact opposite experience, others will have similar or unusable experiences, regardless of what driver they're using. If by "more stable" you mean your display wont go down as often, you may or may not be correct. If you look at the following equation:

    (Total Number Of Features, equally weighed)
    *
    ((Value of Downtime caused by instability (100 being impossible to use, 0 being perfectly stable))/100)

    You will -ALWAYS-, and I mean -without exception- get a higher number on the blobs. Period. That makes the blobs more stable in my book.

    The problem outlined in this article is exactly what countless users have complained about, but the (as another user called them) "freetards" on these boards have been adamant about feature parity and functionality not being a priority over freedom. Computers aren't toys, they're productivity tools. Tools which are worthless unless they work.

    I as a web developer have gotten sick of certain browsers not supporting newer web technologies, such as CSS3, certain JavaScript, and HTML5. Guess what? It got too annoying to try and support all of the ieTards, so I don't bother to code browser-specific workarounds anymore. The same is true of graphics on Linux- its so frustrating to have to conditionally add features based on both hardware and driver limitations - why force these limitations on application developers? The standards are there, and have been there for years!

    I don't think slamming the KDE developers for adding new features is right. Doing so is basically telling the entire industry to bottleneck itself by waiting for the open drivers to play catch up, and by 4,5, sometimes even 6 years. I'm up for ditching the open driver support over slowing down the industry.

  9. #119
    Join Date
    Jun 2010
    Posts
    219

    Default

    Ugh, post edit limit.

    Correcting my above equation:

    0 being Impossible to Use;
    100 being Perfectly Stable.

  10. #120
    Join Date
    Mar 2009
    Posts
    141

    Default

    Quote Originally Posted by bridgman View Post
    I don't understand this comment unless you are talking about r200-class hardware or are using the (relatively stagnant) "classic" mesa drivers -- 3 years ago there was almost no 3D support available on anything past r200, now there is fairly significant GL 2.x available on nearly all post-r200 hardware. Are you running the Gallium3d drivers (which are improving rapidly) or the classic drivers (which aren't changing much) ?
    Quote Originally Posted by kazetsukai
    You can only get the real information by looking at the actual commits and any associated notes with them. You can't honestly think that nothing of value is being done?
    Yes classic drivers. I have both compiled but haven't tested switching over as from what I've read Gallium doesn't quite offer any advantages yet - I would assume especially on my r700 as Gallium3d support is still so new. I'll probably try switching as soon as that changes.

    Quote Originally Posted by kazetsukai
    The problem outlined in this article is exactly what countless users have complained about, but the (as another user called them) "freetards" on these boards have been adamant about feature parity and functionality not being a priority over freedom. Computers aren't toys, they're productivity tools. Tools which are worthless unless they work.
    I understand the pragmatic concerns of users and don't mind those who use blobs if they must, or who write software incorporating unimplemented standards - provided that they really are standards, not proprietary or patented non royalty-free extensions, or otherwise standards whose purpose is merely to impose vendor lock-in and incompatibility.

    I don't however understand why some people fail to see the pragmatism in free drivers. Blobs are merely a stop-gap measure. Perhaps even more important than freedom is the assurance that hardware can be supported in the absence of an IP or Copyright holder with the necessary commercial and economic motivation to support a proprietary driver in a free-software friendly way. Remember companies won't hesitate to write crippleware or make changes which force other software to make less-than-ideal changes in order to interoperate if it is in their interests to do so.

    Even if they're fine for now, that's no guarantee of what might happen 5 or 10 years from now. Imagine if Oracle rather than Nokia bought Trolltech and some big wig decided "you know what, screw you kde guys. From now on we're going to exclusively offer our clients all of the unique advantages that can only come from our innovative ideas which are just way too clever for anybody but us to think up, so we'll patent them and sue anybody else who tries to copy our brilliance". Then you end up with a fork, which is just fine, but having a free implementation is a prerequisite for that.

    Back to the point... I would probably use the blobs if I needed such high performance graphics. I don't really at this point. Actually I run KDE with Xmonad anyway so Kwin isn't as much of a concern here.
    Quote Originally Posted by kazetsukai
    I as a web developer have gotten sick of certain browsers not supporting newer web technologies, such as CSS3, certain JavaScript, and HTML5. Guess what? It got too annoying to try and support all of the ieTards, so I don't bother to code browser-specific workarounds anymore. The same is true of graphics on Linux- its so frustrating to have to conditionally add features based on both hardware and driver limitations - why force these limitations on application developers? The standards are there, and have been there for years!

    I don't think slamming the KDE developers for adding new features is right. Doing so is basically telling the entire industry to bottleneck itself by waiting for the open drivers to play catch up, and by 4,5, sometimes even 6 years. I'm up for ditching the open driver support over slowing down the industry.
    Completely agree on both counts. Hell, I serve my pages as application/xhtml+xml because I really just don't give a f**k about IE. IE is a terrible analogy with this situation though. There's no reason to care about an inferior proprietary implementation when free alternatives are readily available - just because the world is filled with idiot IE6 users. "You mean that thing that gets me to the internet after dialing in to AOL?" ... But that's a rant for another day.

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
  •