Announcement

Collapse
No announcement yet.

Con Kolivas is working on a new scheduler for Desktop/Multimedia/Gaming PCs

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

  • #41
    Originally posted by RealNC View Post
    OK, last test:

    Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?)
    Yes I have Oxygen widget style selected. Using gl2(yuv) in SMplayer menus are corrupted:



    however, when I'm switching menus using this mode movie is smooth, but I have problems you described using xv (0 - Radeon Textured Video). With xv (I used this all time) it's smooth. Maybe with BFS or using NO_NEW_FAIR_SLEEPERS Radeon Textured Video will be fine now (except corrupted menus of course )? We'll see

    And, are you on an AMD or Core I5/I7 CPU?
    I have Athlon X2 64 5000+.

    Comment


    • #42
      Hmm, another AMD user who doesn't have most of those issues. It looks more and more like Intel Core 2 and Pentium owners are the most affected for some reason.

      Or it could be coincidence :P

      Comment


      • #43
        Originally posted by RealNC View Post
        Hmm, another AMD user who doesn't have most of those issues. It looks more and more like Intel Core 2 and Pentium owners are the most affected for some reason.

        Or it could be coincidence :P
        Sabotage! AMD processor has some problems using RADEON textured video and open source RADEON drivers

        I wonder if this change in scheduler will affect benchmarks?

        And I meant win xp before. When running Boinc it was a pain on Duron 850Mhz and on Linux it was just alright.
        Last edited by kraftman; 11 September 2009, 03:37 AM.

        Comment


        • #44
          Originally posted by RealNC View Post
          OK, last test:

          Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?)

          And, are you on an AMD or Core I5/I7 CPU?

          PS:
          I also ran tests with the open source drivers.
          Does oxygen call exaTrapezoid a lot? For me at least that eats a lot of cpu time in xserver which is single threaded so it will cause XV slowdown because they hav to share the cpu time with in xserver.

          You can find out what is taking cpu time in menus with sysprofile running a profile while you open and close menus for an half minute.

          Gnome does use trapezoids a lot which makes gtk very slow. Too bad trapezoids are hard to gpu accelerate so if you are good at drawing smooth lines patches are welcome to add GPU accerlation to open drivers.

          Comment


          • #45
            Originally posted by Kano View Post
            Just compiled a .31 final kernel with bfs 211 patch and it crashed after a few minutes. Does not seem to be that stable yet.
            It's a bit of experimental code... I'd not expect it to be all that stable, Kano...

            Comment


            • #46
              Originally posted by BlackStar View Post
              Ingo may not have meant it like this, but using such hardware really felt like a deliberate attempt to disprove Con's scheduler.
              I'm pretty sure Ingo didn't mean it like that- but unfortunately, everyone over there in LKML appear to have fallen for the "lowest RMS error" folly. If you're doing server stuff, yeah, in the large, you want what Ingo's talking to. However, once you introduce a UI, text or graphic, the rules should change a bit.

              I'm on the fence about this issue, since I haven't really felt any issues with the current scheduler, but if the improvements on single-, dual-, tri- and quad-core systems are repeatable (you know, the hardware desktop PCs actually *have*), then we might have something good on our hands.
              There IS an issue with what we've got as the default. It's not as interactive as the old way of doing things. But, in the same vein, I'm concuring with Con on BFS- it's a demo to show there IS an issue and there can be considerable room for improvement. Ingo and the others are going "but the latency..." not realizing that some latencies are actually needed because humans don't work in lock-step with how the computer works. We have a sliding window atom of attention of about 100msec. If you catch things just right, they seem fluid and are "snappy". Miss the window in the wrong way (and there's several of them...try talking with a delay-line of 150msec applied to what you hear of your speech...) and things feel "laggy" at the least, if not worse. With the introduction of CFS and a few other things, while the overall base performance is impressive, the interactivity suffers while under load.

              The issue is that kernel devs are (rightly) extremely resistant to change on this area. However, if this shows so significant improvements that Android and other distros adapt it (despite being an out of tree patch), we will likely see one of two things:
              1. This makes it into the kernel. (Patch from Con? Yeah, right...)
              2. CFS is improved to match BFS on the desktop.
              I think Con's actually trying to get #2 to happen. That's his stated goals with BFS. He's making it so it largely works, but would be nothing that the kernel crowd would accept into the tree unless there was something like pluggable scheduler modules. And it does seem to show real improvements in interactivity (Even Ingo observed this much...)- only a slight degredation in some areas (Which is where much of the issue at the moment lies- everyone's worrying about lowest latency, which is good, but how they're getting it sacrifices interactivity). For a desktop or handheld device, I suspect once he works the bulk of the kinks out there'll be some more serious looking at what he's trying to tell everyone (yet again...). I'm hoping Ingo takes the hint here and looks into what he missed on CFS and comes up with improvements or an "acceptable" answer to what Con's showing us right now.

              Comment


              • #47
                Originally posted by suokko View Post
                Gnome does use trapezoids a lot which makes gtk very slow. Too bad trapezoids are hard to gpu accelerate so if you are good at drawing smooth lines patches are welcome to add GPU accerlation to open drivers.
                Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.

                Comment


                • #48
                  @Sfartalf

                  Everything should be fine:

                  Comment


                  • #49
                    Originally posted by Svartalf View Post
                    Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.
                    Except that GPU rendering doesn't exactly match the X requirements so you would have to do it with shaders.

                    Comment


                    • #50
                      BFS benchmarks coming next week off 2.6.31 final.
                      Michael Larabel
                      https://www.michaellarabel.com/

                      Comment

                      Working...
                      X