Announcement

Collapse
No announcement yet.

Open-Source GPU Drivers Causing Headaches In KDE 4.5

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

  • hteles
    replied
    Originally posted by hteles View Post
    Hi xeros,

    The only visible problem that i'm getting is with the taskbar thumbnails, they are all black, other than that my desktop seems smoother, by all means i mean kwin seems smoother



    Hi, i'm not using blur neither wobbly windows, or any advanced effects since i'm waiting for a new cpu cooler to arrive from Singapore or my acer will fry short.
    But, i'm not having any render artifacts, neither in kwin or chromium-browser. As a side note i0ve tested the g3d with neverball as someone sugested ( i'm not a gamer ) and after 5 minutes of playing my acer freezed, no sysrq magic could do the trick, but the same thing happens when i'm running more intensive stuff on the acer. How long did you try g3d?

    Specs:

    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

    Just to correct myself.
    I've enabled blur and wobbly windows and they work with the g3d drivers.

    I only see the blur effect on the plasmoids when i click on yawp or the clock and on the launcher menu.
    It works . Better than all the above, flip switch works agains, all those three effects were disabled with stock maverick mesa drivers after kde 4.5.1 update.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by tball View Post
    If you happen to write the bitstream decoder part of a decoder, plz tell me.

    I were far implementing a vdpau state-tracker for gallium3d, but had to give it up. It was just too time consuming writing the bitstream parser from scratch, when I also have to study.
    I'll be committing my project code directly to the WebM project git repository (possibly a branch of the public repository during development). I have a feeling that Michael will probably pick up a story on this when it's complete.

    For now, you can start looking at the VP8 decoder interface source:


    I'd start at vp8_dx_iface.c and go from there. It's not the most well-commented code (massive understatement?), but I might spend some time cleaning that up as well while I'm learning the code-base.

    Leave a comment:


  • tball
    replied
    Originally posted by Veerappan View Post
    Well, we've got a Gallium state tracker for XvMC [1], although I don't know how well it works. There's also been some work done on shader-based H.264 decode acceleration by several groups [2], but I haven't seen anything finished yet.

    I'm currently looking for an adviser for my thesis proposal which will attempt an OpenCL port of the VP8 video decoder. If that pans out, we might have working OpenCL-based decoding of VP8 video on Win/Mac/BSD/Linux in the next year or so. I know Clover isn't finished yet, but when it is, hopefully my project should work just fine on it (and I know someone else on the forums here who may be looking at working on clover).

    It's not that no one wants to work on video acceleration. I will admit that there's very few people who want to try it, and very few people who are willing to invest the required time learning the base technologies and the time doing the actual coding/testing.


    [1] http://www.bitblit.org/gsoc/g3dvl/index.shtml
    [2] http://forum.xbmc.org/showthread.php?t=33802
    If you happen to write the bitstream decoder part of a decoder, plz tell me.

    I were far implementing a vdpau state-tracker for gallium3d, but had to give it up. It was just too time consuming writing the bitstream parser from scratch, when I also have to study.

    Leave a comment:


  • hal2k1
    replied
    Originally posted by bridgman View Post
    The awkward reality is that the "KDE situation" is the worst possible case in many respects, in the sense that KDE developers are starting to make use of features which are also under development in the open drivers. If they were using features which had not yet been implemented the problems would be obvious, and if they were using features which had been added a year or more ago things would probably work pretty well, but since they are using features which were exposed very recently, which are working well with many applications, but which still being tested and fixed on others there is bound to be a big heap of pain unless the two groups coordinate their efforts.
    Isn't there a relatively painless solution here? The KDE developers say they use only a very limited set of OpenGL functions new to KDE 4.5.

    KDE is currently blamed for errors in external components: the graphic drivers. I am lately reading quite some crap (e.g. on it news today) that we KWin devs knew about problems in the drivers and …


    The most important fact in this list is, that KWin does not enable any functionality the driver does not claim support for it! Furthermore we have several runtime checks to ensure that our users have a smooth experience even if the drivers are claiming support for extensions they do not support. Many of these checks have been added in the 4.4 and 4.5 release cycle.

    Now that I have explained all our checks we did to ensure a smooth user experience, I want to explain how it could happen that there are regressions in 4.5. In 4.5 we introduced two new features which require OpenGL Shaders: the blur effect and the lanczos filter. Both are not hard requirements. Blur effect can easily be turned off by disabling the effect and the lanczos filter is controlled by the general effect level settings which is also used for Plasma and Oxygen animations. Both new features check for the required extensions and get only activated iff the driver claims support for it. So everything should be fine, shouldn?t it?
    It turns out that KDE 4.5 on my system (OpenGL renderer string: Mesa DRI R600 (RV710 954F) 20090101 TCL) runs OK, but compositing is disabled. kwin compositing used to work just fine in KDE 4.4, so there is a regression.

    So, all that should be necessary, for now, is for open source drivers to remove the "claimed support" for the new OpenGL extensions that are used by KDE 4.5.

    This would have the effect that when using open source drivers in KDE 4.5, the blur effect and the lanczos filter would not be available, but other kwin compositing features would be. This would remove the kwin regressions for KDE 4.5.

    Later, when the problematic OpenGL extensions are debugged, the open source driver can once again claim support, and then the kwin blur effect and the lanczos filter would magically be re-instated.

    Is this too much of a problem, really?

    Leave a comment:


  • hteles
    replied
    Originally posted by xeros View Post
    So, you mean the problem with KDE 4.5.x is fixed in xorg-edgers ppa for r300g?
    Could you post some more information is it stable combination for yours hardware? I'm thinking about giving a try Kubuntu 10.10 and r300g with or without xorg-edgers ppa, too for my r3xx cards.
    Hi xeros,

    The only visible problem that i'm getting is with the taskbar thumbnails, they are all black, other than that my desktop seems smoother, by all means i mean kwin seems smoother

    I ran G3d from Kubuntu ppa and the latest mesa etc. Blur was enabled, but was displayed incorectly. Using G3d I experienced problems like mouse being choppy, plasma was sometimes unresponsive for a while and there where graphical glitches in Firefox.
    Hi, i'm not using blur neither wobbly windows, or any advanced effects since i'm waiting for a new cpu cooler to arrive from Singapore or my acer will fry short.
    But, i'm not having any render artifacts, neither in kwin or chromium-browser. As a side note i0ve tested the g3d with neverball as someone sugested ( i'm not a gamer ) and after 5 minutes of playing my acer freezed, no sysrq magic could do the trick, but the same thing happens when i'm running more intensive stuff on the acer. How long did you try g3d?

    Specs:

    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

    Leave a comment:


  • Veerappan
    replied
    Originally posted by pingufunkybeat View Post
    There are probably tens of millions of Linux users in the world.

    None of them want to do it.

    That's why there is no work on video decode acceleration.
    Well, we've got a Gallium state tracker for XvMC [1], although I don't know how well it works. There's also been some work done on shader-based H.264 decode acceleration by several groups [2], but I haven't seen anything finished yet.

    I'm currently looking for an adviser for my thesis proposal which will attempt an OpenCL port of the VP8 video decoder. If that pans out, we might have working OpenCL-based decoding of VP8 video on Win/Mac/BSD/Linux in the next year or so. I know Clover isn't finished yet, but when it is, hopefully my project should work just fine on it (and I know someone else on the forums here who may be looking at working on clover).

    It's not that no one wants to work on video acceleration. I will admit that there's very few people who want to try it, and very few people who are willing to invest the required time learning the base technologies and the time doing the actual coding/testing.


    [1] http://www.bitblit.org/gsoc/g3dvl/index.shtml
    [2] http://forum.xbmc.org/showthread.php?t=33802

    Leave a comment:


  • rvdboom
    replied
    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.
    I don't have the same experience. I had a lot of issues with blobs when upgrading kernels or X11, while I never had such issues with open drivers.
    Early KDE4 users remembers the large amount of issues that occured with Nvidia blobs, while open drivers worked well.
    Personnally, I'm 100% for open drivers. I may sometimes have some issues with compositing or stuff like that, but never to the point that X do not start and I cannot work at all.

    Leave a comment:


  • kraftman
    replied
    Originally posted by xeros View Post
    So, you mean the problem with KDE 4.5.x is fixed in xorg-edgers ppa for r300g?
    Could you post some more information is it stable combination for yours hardware? I'm thinking about giving a try Kubuntu 10.10 and r300g with or without xorg-edgers ppa, too for my r3xx cards.
    I ran G3d from Kubuntu ppa and the latest mesa etc. Blur was enabled, but was displayed incorectly. Using G3d I experienced problems like mouse being choppy, plasma was sometimes unresponsive for a while and there where graphical glitches in Firefox.

    Leave a comment:


  • xeros
    replied
    Originally posted by marek View Post
    FBO requires KMS.

    EXT_fbo is supported in all Radeon drivers except for R100.
    ARB_fbo is supported in all Radeon Gallium drivers (R300, R600), though the "multisample" subset is not currently useful.
    Thank you very much. r300g looks very promising and really tempts to try it.

    Leave a comment:


  • xeros
    replied
    Originally posted by hteles View Post
    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.

    ...

    Thank you all.
    So, you mean the problem with KDE 4.5.x is fixed in xorg-edgers ppa for r300g?
    Could you post some more information is it stable combination for yours hardware? I'm thinking about giving a try Kubuntu 10.10 and r300g with or without xorg-edgers ppa, too for my r3xx cards.

    Leave a comment:

Working...
X