Announcement

Collapse
No announcement yet.

Is Compiz On Its Deathbed?

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

  • #46
    Compiz is not dying short term, thanks to Daniel Van Vugt, who is responsible for lots of patches that dramatically improve the performance and reduce the power usage of both Compiz and Unity (on top of Compiz). Some is avaible in Ubuntu 12.04 Beta 1, but a alot more will be integrated before Ubuntu 12.04 releases. It fucking flies with all of them.

    Comment


    • #47
      Originally posted by drago01 View Post
      Well I asked you what you miss in mutter because you called it "just basics" and one of your concerns was performance. I used Owen's benchmarks to back up my claim that "there is no reason for mutter to be any slower then compiz". It might be the case on your system but that isn't just because "mutter is slow" and "compiz is fast" but something specific in your configuration causes mutter to run slower then it ought to be (hence why I asked for a bug report).
      Okay, i use an RT-kernel (full preemption) all of the time. Now, with both Cinnamon and GS, i experience lag in GUI. one example, Cinnamon's menu often takes a second to load (when it should take no time at all). ... But it is similar with GS, just not as bad, and in different situations. But you're right, it could be something in my configuration, the fact that i use RT (all of the time), the fact that i am using the Nvidia proprietary driver, or any number of other things...But the whole bug report thing, is a waste of *my time*, being as i know GnomeShell isn't the sort of Desktop experience that i want, and IMO isn't a good fit for proaudio, either. (partially because of xrun issues, partially because i don't like the way it handles windows/applications/or my desktop in general and partially because there are more flexible reliable alternatives)...

      Originally posted by drago01 View Post
      Not true you are currently talking to one and this was the first time I see any reports regarding xruns.
      I initially mentioned it on the GnomeShell list, right after Gnome3 was released. admittedly, the message was very heated (I was pissed at the time) as GnomeShell was complete garbage, at that point, on my Desktop... To explain what i mean by garbage; Archlinux was the first to have G3 come through as an 'update' to replace gnome2. At that point, my Gnome Desktop become totally useless, because of a combination of xruns and even worse GnomeSehll && Nvidia blob not working (very well) together. (ie: things like garbled GFX/GL, apps being unusable, etc). Gnome-devs recommended using Nouveau (which wasn't an option because of apps that i use that require Nvidia / proper GL)... Then after some tinkering, my desktop became Gnome3/compiz 0.9.x (much like how it was before the upgrade to GnomeShell). The GS xrun problem has been mentioned on LAU (linux-audio-user-list) on several occasions (over the last year), and i have also read about it in other forums. Generally speaking, the odd (non-specific) daemon can cause xruns, so it's not surprising that GS with all of it's bling could do the same. (and i have a quadcore/SATA6g/8g DDR3/pci soundcard, proaudio, not consumer grade), so it's not like i'm running an older core 2 duo and crap hardware or something)... years ago, this was an issue with compiz too, but for me it hasn't been in quite some time.

      You probably haven't seen bug reports, because unless someone actually *really* has their heart set on using GS, they probably don't go to the effort to file a bug report, but instead just moved on to a lighter DE/WM, or one they know doesn't cause them issues.

      Originally posted by drago01 View Post
      Can't recall seeing any such bug report or mailing list post.
      ...then you don't recall seeing/reading it...and to be clear, i never filed a bug report - because i have no intention of using GS, i only muck around with it, every now and again when i see progress or hear about a new extension that may be of interest. I sort of view GS as a toy, not as something to use in production.

      Originally posted by drago01 View Post
      The window manager / compositor should not matter for audio at all. If it does something else is just broken.

      How familiar are you with Both RT-kernels and proaudio (in linux)???? While in theory it shouldn't, that doesn't mean in practice that it wont. Lets put it this way ~ If a process monopolizes a little too much cpu time, you can get xruns...
      Last edited by ninez; 03-06-2012, 02:33 PM.

      Comment


      • #48
        Originally posted by d2kx View Post
        Compiz is not dying short term, thanks to Daniel Van Vugt, who is responsible for lots of patches that dramatically improve the performance and reduce the power usage of both Compiz and Unity (on top of Compiz). Some is avaible in Ubuntu 12.04 Beta 1, but a alot more will be integrated before Ubuntu 12.04 releases. It fucking flies with all of them.
        good point. Daniel is doing lots of good stuff for compiz. The cpu-fix cut compiz' cpu usage in half, on my hardware.

        Comment


        • #49
          Originally posted by ninez View Post
          Okay, i use an RT-kernel (full preemption) all of the time. Now, with both Cinnamon and GS, i experience lag in GUI. one example, Cinnamon's menu often takes a second to load (when it should take no time at all). ... But it is similar with GS, just not as bad, and in different situations.
          Does/did this happen more then once in one session? The textures are cached after the first load so it should show up instantaneously after being loaded once. (Yes the first load shouldn't be slow either but even if it is at least subsequent accesses shouldn't be).

          But you're right, it could be something in my configuration, the fact that i use RT (all of the time), the fact that i am using the Nvidia proprietary driver, or any number of other things...But the whole bug report thing, is a waste of *my time*, being as i know GnomeShell isn't the sort of Desktop experience that i want, and IMO isn't a good fit for proaudio, either. (partially because of xrun issues, partially because i don't like the way it handles windows/applications/or my desktop in general and partially because there are more flexible reliable alternatives)...
          OK, fair enough. Just for the record which CPU / GPU are you using (or did you use back then) ?

          I initially mentioned it on the GnomeShell list, right after Gnome3 was released. admittedly, the message was very heated (I was pissed at the time)
          Ah OK, I tend to skip such emotionally loaded posts because they almost never result into a useful discussion. I'd advise you to keep emitions out of such report (not only for GNOME but when talking to any other projects.); otherwise you just trigger defensive reactions and no constructive discussion on the issues you raise.

          as GnomeShell was complete garbage, at that point, on my Desktop...

          To explain what i mean by garbage; Archlinux was the first to have G3 come through as an 'update' to replace gnome2. At that point, my Gnome Desktop become totally useless, because of a combination of xruns and even worse GnomeSehll && Nvidia blob not working (very well) together. (ie: things like garbled GFX/GL, apps being unusable, etc). Gnome-devs recommended using Nouveau (which wasn't an option because of apps that i use that require Nvidia / proper GL)
          The advise the use nouveau was because the NVIDIA driver had a bug where we worked with NVIDIA to identify it. They told us that they where working on a fix, because we didn't have access to the drivers source code there was no way for us to fix it so we advised users to use nouveau at this time. The bug got fix a while ago though.

          ... Then after some tinkering, my desktop became Gnome3/compiz 0.9.x (much like how it was before the upgrade to GnomeShell). The GS xrun problem has been mentioned on LAU (linux-audio-user-list) on several occasions (over the last year), and i have also read about it in other forums.
          Do you have a link to any of this discussions?

          Generally speaking, the odd (non-specific) daemon can cause xruns, so it's not surprising that GS with all of it's bling could do the same. (and i have a quadcore/SATA6g/8g DDR3/pci soundcard, proaudio, not consumer grade), so it's not like i'm running an older core 2 duo and crap hardware or something)... years ago, this was an issue with compiz too, but for me it hasn't been in quite some time.
          With that alone I cannot explain why it happens even in the case where the compositor monopolizes a whole CPU you'd have three other cores left. And neither gnome-shell nor compiz ever put any pressure on all CPU cores. Maybe you where running in a situation where the bus bandwidth was saturated due to texture transfers. Hard to say without debugging it.

          You probably haven't seen bug reports, because unless someone actually *really* has their heart set on using GS, they probably don't go to the effort to file a bug report, but instead just moved on to a lighter DE/WM, or one they know doesn't cause them issues.

          ...then you don't recall seeing/reading it...and to be clear, i never filed a bug report - because i have no intention of using GS, i only muck around with it, every now and again when i see progress or hear about a new extension that may be of interest. I sort of view GS as a toy, not as something to use in production.
          OK fine but OTOH you can't blame us for not fixing bugs that we don't hit ourselves and do not get reported.

          While in theory it shouldn't, that doesn't mean in practice that it wont..
          Sure let me quote my comment again I said "should not matter for audio at all. If it does something else is just broken." that does not imply that it never happens I just said that when this happens something is broken and has to be fixed. And that "something" is at a lower level then the window or compositing manager. (By swapping it you are dealing with the symptoms and leave the root cause as is).

          Comment


          • #50
            Originally posted by drago01 View Post
            Does/did this happen more then once in one session? The textures are cached after the first load so it should show up instantaneously after being loaded once. (Yes the first load shouldn't be slow either but even if it is at least subsequent accesses shouldn't be).
            Yes, it does.

            Originally posted by drago01 View Post
            OK, fair enough. Just for the record which CPU / GPU are you using (or did you use back then) ?
            AMD Phenom II 965 Black edition (3.2ghz quadcore) - This machine is my primary (Linux) Desktop... i could, but don't overclock it. I've also got an i7 in my Mac (which also runs Archlinux/dualboot) although, i don't think i've ever used GnomeShell on that machine, as it is primarily used for it's Mac side.

            Nvidia card at the time, *i think* was Geforce 9800GT - but i gave that card to my dad. Now, i am using Nvidia GTX 295 - but i have several other nvidia cards laying around, or in other machines, too.

            Originally posted by drago01 View Post
            Ah OK, I tend to skip such emotionally loaded posts because they almost never result into a useful discussion. I'd advise you to keep emitions out of such report (not only for GNOME but when talking to any other projects.); otherwise you just trigger defensive reactions and no constructive discussion on the issues you raise.
            Yup... i agree. I was pretty bitter stressed out at the time, and GS put a fork in the road, when i was actually *needing" my computer to get real work done, it also blew me away that Gnome3 was even being released in the state it was in at the time.

            Originally posted by drago01 View Post
            The advise the use nouveau was because the NVIDIA driver had a bug where we worked with NVIDIA to identify it. They told us that they where working on a fix, because we didn't have access to the drivers source code there was no way for us to fix it so we advised users to use nouveau at this time. The bug got fix a while ago though.
            I already all know this stuff.

            Originally posted by drago01 View Post
            Do you have a link to any of this discussions?
            I probably do, but i will have to search through my inbox, as i usually hold on to most of the LAU emails, as from time to time ~ there is useful info in there, that i might want find useful down the road. I'll have a look.

            Originally posted by drago01 View Post
            With that alone I cannot explain why it happens even in the case where the compositor monopolizes a whole CPU you'd have three other cores left. And neither gnome-shell nor compiz ever put any pressure on all CPU cores. Maybe you where running in a situation where the bus bandwidth was saturated due to texture transfers. Hard to say without debugging it.
            I think your making the grand assumption that my 3 (or even 4) cores aren't already busy with other processing. It is quite typical on my desktop to be running 30-40 applications (all proaudio, using/requiring RT-scheduling), right now, *idling* i am using 34% of my CPU(s), keep in mind that i am running 28 proaudio applications, not including Firefox, gedit and musescore. Not one of my cores is idling at zero (or even close to zero). As for the latter part of your comment, not sure, wouldn't want to speculate either.

            Originally posted by drago01 View Post
            OK fine but OTOH you can't blame us for not fixing bugs that we don't hit ourselves and do not get reported.
            Who said i blame you? I don't use GS, so i don't do bug reports for it.

            Originally posted by drago01 View Post
            Sure let me quote my comment again I said "should not matter for audio at all. If it does something else is just broken." that does not imply that it never happens I just said that when this happens something is broken and has to be fixed. And that "something" is at a lower level then the window or compositing manager. (By swapping it you are dealing with the symptoms and leave the root cause as is).
            Fair enough. But by swapping out GS/mutter, my problem is completely gone. and theoretically, if i had left GS - i would be left with a Linux Desktop that i wouldn't even want to use, so it really doesn't matter if i left the 'root cause' there or not ~ because it exists in software, that really isn't what i am looking for to begin with. ~ let's put it this way, the GnomeShell package (currently) wouldn't even be installed on my machines, if it wasn't a dependency for things like 'gnome-tweak-tool'.
            Last edited by ninez; 03-06-2012, 04:04 PM.

            Comment


            • #51
              Originally posted by ninez View Post

              I think your making the grand assumption that my 3 (or even 4) cores aren't already busy with other processing. It is quite typical on my desktop to be running 30-40 applications (all proaudio, using/requiring RT-scheduling), right now, *idling* i am using 34% of my CPU(s), keep in mind that i am running 28 proaudio applications, not including Firefox, gedit and musescore. Not one of my cores is idling at zero (or even close to zero). As for the latter part of your comment, not sure, wouldn't want to speculate either.
              Wow! That's more overhead than even I thought rt would have, based on our earlier discussions.
              Have you tried adjusting the slack timer so it can avoid some wakeups?

              Comment


              • #52
                Originally posted by liam View Post
                Wow! That's more overhead than even I thought rt would have, based on our earlier discussions.
                Have you tried adjusting the slack timer so it can avoid some wakeups?
                Hey liam, let me clarify a little.

                When i say 'idle', i really mean something along the lines of, 'as idle as it is can be'. ie: even in an idle state, their is a lot of processing going on. So it's not so much overhead for RT 'specifically', this is just overhead of running certains programs, that will use cpu regardless of whether or not, you actually can hear what they are doing (or processing).

                I haven't played around with /proc/<procid>/task/<task_id>/timer_slack_ns (if that is what you mean)

                I've seen that cgroups can manage this stuff, but i haven't investigated it.

                the best tunables that i have played with in the past, that are rt-related that yielded good results (but this was latency related) were these three tunables;

                /proc/sys/kernel/sched_latency_ns
                /proc/sys/kernel/sched_min_granularity_ns
                /proc/sys/kernel/sched_wakeup_granularity_ns

                i had to run tests over and over until i got the right mix between them. (using standard rt-related tools, like Cyclitest). But these days, things run very smooth and i haven't felt the need to be as crazy about those sorts of tweaks, as my box has been working very well.
                Last edited by ninez; 03-06-2012, 10:42 PM.

                Comment


                • #53
                  Originally posted by ninez View Post
                  Hey liam, let me clarify a little.

                  When i say 'idle', i really mean something along the lines of, 'as idle as it is can be'. ie: even in an idle state, their is a lot of processing going on. So it's not so much overhead for RT 'specifically', this is just overhead of running certains programs, that will use cpu regardless of whether or not, you actually can hear what they are doing (or processing).

                  I haven't played around with /proc/<procid>/task/<task_id>/timer_slack_ns (if that is what you mean)

                  I've seen that cgroups can manage this stuff, but i haven't investigated it.

                  the best tunables that i have played with in the past, that are rt-related that yielded good results (but this was latency related) were these three tunables;

                  /proc/sys/kernel/sched_latency_ns
                  /proc/sys/kernel/sched_min_granularity_ns
                  /proc/sys/kernel/sched_wakeup_granularity_ns

                  i had to run tests over and over until i got the right mix between them. (using standard rt-related tools, like Cyclitest). But these days, things run very smooth and i haven't felt the need to be as crazy about those sorts of tweaks, as my box has been working very well.
                  Hey ninez,

                  That's what I assumed you meant by idle, namely, programs that were still in active memory but not actively processing.
                  Assuming the programs aren't just terribly written, or need to do synchronous logging even when idle (I think FF still does this), that percentage is likely due to RT_PREEMPT (I'd guess timer setup/breakdown is the main culprit which is why I mentioned slack timer...BTW, cgroup management is going to be easier to do than per proc... https://lkml.org/lkml/2011/10/11/246). However, if your system is working good enough, I sure as hell wouldn't screw with it My tuning experience has been very hit or miss. The problem, of course, is defining the problem and creating tests. Unfortunately, for ordinary desktop usage (i.e., encompassing more than irq request delay), it is very hard to measure, and people don't even agree what we should be measuring. If we did, there would be no ambiguity about which scheduler is better for general desktop usage

                  BTW, I don't recall if I told you but I had to uninstall that RT kernel I got from the stanford repos. It was wreaking a wide swathe of destruction all through my desktop.

                  Best/Liam

                  Comment


                  • #54
                    Originally posted by liam View Post
                    That's what I assumed you meant by idle, namely, programs that were still in active memory but not actively processing.
                    That's not entirely correct, some stuff is 'actively processing', even when everything is pretty much idle. For example, i have several instruments (live inputs) ie: guitar, a couple mics, kaossilator - which even when not being played, will be passing a signal on through to other clients (such as DSP effects)... so some of these apps are always using CPU. which is why my CPU usage seemed high.

                    Originally posted by liam View Post
                    Assuming the programs aren't just terribly written, or need to do synchronous logging even when idle (I think FF still does this), that percentage is likely due to RT_PREEMPT (I'd guess timer setup/breakdown is the main culprit which is why I mentioned slack timer...BTW, cgroup management is going to be easier to do than per proc... https://lkml.org/lkml/2011/10/11/246). However, if your system is working good enough, I sure as hell wouldn't screw with it My tuning experience has been very hit or miss. The problem, of course, is defining the problem and creating tests. Unfortunately, for ordinary desktop usage (i.e., encompassing more than irq request delay), it is very hard to measure, and people don't even agree what we should be measuring. If we did, there would be no ambiguity about which scheduler is better for general desktop usage
                    For the most part, i stay away from cgroups (with RT/jackd), I don't think i really need it, at this point. I probably could get it working, but it doesn't seem worth the effort, my system is very reliable and solid and although i do like to screw things up sometimes ;p ... this machine, always needs to be working well.


                    Originally posted by liam View Post
                    BTW, I don't recall if I told you but I had to uninstall that RT kernel I got from the stanford repos. It was wreaking a wide swathe of destruction all through my desktop.
                    really?

                    Comment

                    Working...
                    X