Announcement

Collapse
No announcement yet.

Con Kolivas Fixes Up GUI-Related Stalls In Mesa

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

  • evasb
    replied
    Con Kolivas is a genius.

    Leave a comment:


  • pixelherodev
    replied
    Originally posted by raster View Post

    No - it changes the priority of THREADS that mesa creates - and this means anything that is using Mesa to render (your compositor, games, browsers these days etc.) can be affected as these are silent internal threads Mesa may be spinning off to do background work as a result of requests via regular OpenGL APIs etc. Mesa explicitly lowered the priority of these threads to IDLE so they don't impact other applications threads as much - that was already the case. This patch just lowers the priority less than before to a type (IDLE now BATCH) to where it gets more regular scheduling time, so they may now impact other threads more by taking time slices away, but may also provide results in a more timely fashion too. It depends on what the threads were/are doing and a whole host of other complex system state.
    Ahh, gotcha. Thanks for clarifying.

    Leave a comment:


  • uentity
    replied
    You can read original discussion of this patch here: http://ck-hack.blogspot.com/2020/05/...for-linux.html
    Seems that it really related to MuQSS performance, s.t. Con even provided a custom Mesa build (with this patch applied) alongside with MuQSS patchset for kernel v5.6.

    Leave a comment:


  • kcrudup
    replied
    Originally posted by Zan Lynx View Post
    Oh, and I bet why some people see the problem Con found, and other people don't, is the number of CPU threads available.
    This is likely true- as I have an i7 running KDE (X11) with all the compositor bells and whistles, yet rarely saw stutters before the patch- but every now and then while building code (always multithreaded) opening a new konsole would have a stutter as the effects would launch. I'll have to run a test to be sure, but I'm pretty sure that doesn't happen now.

    Leave a comment:


  • Guest
    Guest replied
    Hm, I wonder if this will stop the desktop and Chrome from stuttering when I'm playing Warhammer.

    Leave a comment:


  • oiaohm
    replied
    Does make you wonder how many issues with latency is the scheduler vs the scheduler being told to-do X that is wrong.

    Leave a comment:


  • Zan Lynx
    replied
    Oh, and I bet why some people see the problem Con found, and other people don't, is the number of CPU threads available.

    This latency thing is probably only found on CPUs like a 4c/4t Intel i5 or a 2c i3. I don't see many graphics output programs that use all 8 threads at 100% on an i7. With 8 CPU threads available there should be plenty of room to run a few SCHED_IDLE tasks.

    Using Intel i7's, AMD Ryzens and Power9 64 thread CPUs is probably why I've never experienced the Wayland lag problems other people have reported. Mouse cursor freezes? Not for me.

    But if I recall correctly Con Kolivas used to do a lot of testing on four core i5s for his scheduler work. Four cores was kind of an ideal point for his BFS.

    Leave a comment:


  • Zan Lynx
    replied
    I haven't looked into the rest of the Mesa code so I don't know why this might be so important. But I can guess.

    There might be a limited pool of threads. Once all the thread pool is occupied by SCHED_IDLE threads no high priority threads can be added until they clear out.

    Or it might be a memory pool. Maybe the idle thread is supposed to clean up unused objects but it isn't running. Then some high priority threads needs an object, but there's no room available until the idle thread cleans out the old ones.

    Or any other kind of object. Perhaps the GPU has a limited number of textures or semaphores or something else.

    It's almost certainly something similar to garbage collection in Java. Java runs fine without garbage collection. Right up to the point that it runs out of RAM. At that point everything stops until it has finished a full stop-the-world garbage collection cycle. So it is much better for the program performance if it runs a continuous series of small garbage collections at a low priority, but not such a low priority that it runs out of RAM.

    Leave a comment:


  • Dr_ST
    replied
    For what is worths, in the past I encountered regular freezes using BFS + nvidia driver ... Not sure if this is related though, but this situation caused me to avoid BFS and MuQSS since then. I may give a shot one day when they'll be available in mainstream distribution.

    Leave a comment:


  • puleglot
    replied
    Originally posted by TemplarGR View Post
    Radeonsi does seem to have lots of optimizations for Mesa 20.1 even without Kolivas's patch.
    Of course, I compared vanilla 20.1_rc2 and 20.1_rc2 with Kolivas's patch.

    Leave a comment:

Working...
X