Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 58

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

  1. #41

    Default

    Quote 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:

    http://img34.imageshack.us/img34/6769/zrzutekranu1o.png

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

  2. #42
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    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

  3. #43

    Default

    Quote 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; 09-11-2009 at 04:37 AM.

  4. #44
    Join Date
    Jan 2009
    Posts
    117

    Default

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

  5. #45
    Join Date
    Jun 2006
    Posts
    3,046

    Default

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

  6. #46
    Join Date
    Jun 2006
    Posts
    3,046

    Default

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

  7. #47
    Join Date
    Jun 2006
    Posts
    3,046

    Default

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

  8. #48

    Default

    @Sfartalf

    Everything should be fine:

    http://lkml.org/lkml/2009/9/10/229

  9. #49
    Join Date
    Jan 2009
    Posts
    117

    Default

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

  10. #50

    Default

    BFS benchmarks coming next week off 2.6.31 final.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •