Announcement

Collapse
No announcement yet.

Open-Source GPU Drivers Causing Headaches In KDE 4.5

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

  • 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?

    Comment


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

      Comment


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

        Comment


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

          Comment


          • Originally posted by hteles View Post
            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
            Hi, I ran it till I switched to Arch Linux, so about two or three weeks ago. I had kwin effects enabled for all the time as far as I remember. I played simple games like foobilard and I didn't have any hard lockups, but the problems mentioned before.

            Comment


            • Originally posted by Veerappan View Post
              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.
              Well what I need is a mpeg 2 bitstream parser. I was making one, when I realised a much better way of making it by looking at mplayer's code.

              But starting from scratch with the bitstream parser is just too time consuming for me. I have a personal git repo, with galium/mesa code able to running vdpauinfo.

              Comment


              • 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.
                Features which have been a part of the OpenGL spec for -years-. They're no longer in active development for the blobs, they're already past QA and several rounds of bugfixing. The problematic Blur effect only uses OpenGL 2.x and GLSL.

                Originally posted by bridgman View Post
                ...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.
                It isn't KDE's responsibility to fix problems with Open Drivers. I can't really think that splitting KDE.org's resources between desktop development and driver bugfixes as worthwhile or productive. All you do is slow the development of KDE in that case.

                This isn't super-recent OpenGL 3 instructions that are causing problems, its OpenGL 2 / GLSL instructions which have proven themselves in the industry as a solidified de facto standard. Make no mistake, these are not KDE bugs and they're not problems with hardware needing to be too new. These are problems with Open Drivers failing to keep up with even 5 year old standards mostly because they aren't implemented anywhere, and are thus a low priority to fix.

                So when KDE 4.6+ rolls around with the new OpenGL 3 spec, it is going to be extremely problematic for people with Open Drivers. But this is how progress is made. If enough people use KDE 4.6/4.7 with these features and have Open Drivers, bugs will get filed, triaged, and subsequently fixed. The best thing KDE can do for these drivers is to keep setting the bar higher and pushing newer versions of the spec. Driver developers will then respond to those increased expectations, since for the first time there is high demand for said features.

                Comment


                • Originally posted by marek View Post
                  ATI have never released a GL2 GPU. Some GLSL features are not supported by hardware, the GL2 non-power-of-two textures are not supported at all. R300 up to R400 don't fully support separate stencil. NV30 has similar limitations (like separate blend equations are not supported).
                  Sorry R300 gpu is DX7. It's not a opengl 2.0 gpu and can't be. I think R500 is where you have to go for that. NV30 is nvidia 5 series. That's a dx8 gpu. Not a dx9 gpu and not a opengl 2.0 gpu.
                  ATI's x1300 to x1950 and nvidia's 6xxx series should be the bottom line in my mind. Everything else is a decade old and completely unsupported by hardware vendors on any OS except for maybe legacy windows 98 drivers hanging around on their website.
                  As much as linux wants to support this stuff and brag about supporting unsupported hardware it's going to make mesa and X11 a mess. Sure it's 180 to 150nm and likely to keep working and working and never die but really it has to be let go as it's a boat anchor to modernization of Linux.

                  Comment


                  • Originally posted by kazetsukai View Post
                    So when KDE 4.6+ rolls around with the new OpenGL 3 spec, it is going to be extremely problematic for people with Open Drivers. But this is how progress is made.
                    Progress? Bullshit. There is no reason to demand GL3, there is no feature in GL3 you need for desktop effects. The top-notch games don't need it, so you don't need it either. GL2 and D3D9 are far more powerful than you seem to imagine. Game consoles are stuck in the D3D9 level of features and there are lots of games with very impressive graphics. I don't get why people keep repeating the same GL3 bullshit over and over again, yet still they have probably never read the GL3 spec. Even today, GL3 is still niche in the game industry, and that won't change anytime soon unless Intel and Apple implement GL3 in their drivers/systems, that's more than 50% of the market, plus there are tons of legacy ATI and NVIDIA hardware out there.

                    Originally posted by kazetsukai View Post
                    Driver developers will then respond to those increased expectations, since for the first time there is high demand for said features.
                    Driver developers already respond to much higher expectations than KDE could ever make. There are even games, you know.

                    Comment


                    • Originally posted by Hephasteus View Post
                      Sorry R300 gpu is DX7. It's not a opengl 2.0 gpu and can't be.
                      R100 is DX7, R200 is DX8, R300-R500 is DX9. GL2 is somewhere between DX9 and DX10, it's basically DX9 with additional features the DX9 hardware doesn't have. The R300 hardware interface matches DX9 API almost *exactly*, see the r5xx docs, it's all there.

                      Originally posted by Hephasteus View Post
                      NV30 is nvidia 5 series. That's a dx8 gpu. Not a dx9 gpu and not a opengl 2.0 gpu.
                      NV30 is also within limits of D3D9, but isn't within limits of GL2.

                      You also seem to be forgetting about Intel, which is approximately 50% of the GPU market and those are mainly D3D9 GPUs too.

                      Originally posted by Hephasteus View Post
                      ATI's x1300 to x1950 and nvidia's 6xxx series should be the bottom line in my mind. Everything else is a decade old and completely unsupported by hardware vendors on any OS except for maybe legacy windows 98 drivers hanging around on their website.
                      You are so wrong. Aero in Windows 7 supports the lowest level of D3D9 hardware even today, including R300, NV30, and Intel GMA.

                      I don't think Linux can afford killing its userbase by dropping hardware support. KDE obviously doesn't care.

                      Comment

                      Working...
                      X