Wayland's Weston Gets Patch For High Priority GPU Support

[phoronix]

Phoronix: Wayland's Weston Gets Patch For High Priority GPU Support

Last year Intel open-source developers squared away priority GPU scheduling support within their kernel DRM driver and from Mesa are exposing support for "high priority" GPU processes via the EGL_IMG_context_priority extension. There hasn't been any major real-world user of this support yet, but a patch would allow Wayland's Weston OpenGL renderer to make use of it...

http://www.phoronix.com/scan.php?page=news_item&px=Weston-EGL-High-Priority-Patch

[SethDusek]

Is there any way to do the same with a vulkan renderer?

[polarathene]

Does this mean less chance of the UI freezing up or stuttering under heavy load(like compiling?). I have an old laptop with only 2 cores, no hyper threading, if both cores are at full load like when compiling packages, it's not too responsive/smooth to use. Even moving windows around or clicking UI buttons can slow to a crawl.

In my case the laptop won't benefit, I don't think Core2Duo has an iGPU? At least I think the laptop only has old ATI/Radeon GPU. It's only been running X11, haven't tried Wayland with it. Plasmashell today for some reason used up to 900MB of RAM(<200MB at boot) when a single tab Chromium browser played a youtube video fullscreen for a few minutes. The laptop only has 2GB RAM(usually averages 800MB usage) so this ended up filling up the RAM and I guess was more of a disk I/O/swap slowdown at that point where something like this GPU priority support wouldn't make a difference?

[droste]

Does this mean less chance of the UI freezing up or stuttering under heavy load(like compiling?). I have an old laptop with only 2 cores, no hyper threading, if both cores are at full load like when compiling packages, it's not too responsive/smooth to use. Even moving windows around or clicking UI buttons can slow to a crawl.

In my case the laptop won't benefit, I don't think Core2Duo has an iGPU? At least I think the laptop only has old ATI/Radeon GPU. It's only been running X11, haven't tried Wayland with it. Plasmashell today for some reason used up to 900MB of RAM(<200MB at boot) when a single tab Chromium browser played a youtube video fullscreen for a few minutes. The laptop only has 2GB RAM(usually averages 800MB usage) so this ended up filling up the RAM and I guess was more of a disk I/O/swap slowdown at that point where something like this GPU priority support wouldn't make a difference?

Not really, none of this is related to the GPU and I doubt that X11 is the problem here.

You can try if changing CPU governor helps. I have less UI stutters with 'schedutil'.

Check what is currently used:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

If not schedutil then run this:

echo schedutil | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

This will be reset after a reboot.

[wizard69]

i hate to say this but if you want better performance you need a laptop upgrrade. While you can tweak things some, more RAM for example, the reality is you can only get so much out of a Core2Dou. I hade a similarly equied MBP that suffered similarly, it got to the point nothing ran well on it.

Your only other option is to go with a very light weight Windows manager and play around with the scheduling software. In the end though you only have so much horse power to work with.

By the way im not dismissing the imptovements that can be made through software. The problem is this generation of hardware has ran its course. Developers seldom bither with improvements to such old hardware.

Does this mean less chance of the UI freezing up or stuttering under heavy load(like compiling?). I have an old laptop with only 2 cores, no hyper threading, if both cores are at full load like when compiling packages, it's not too responsive/smooth to use. Even moving windows around or clicking UI buttons can slow to a crawl.

In my case the laptop won't benefit, I don't think Core2Duo has an iGPU? At least I think the laptop only has old ATI/Radeon GPU. It's only been running X11, haven't tried Wayland with it. Plasmashell today for some reason used up to 900MB of RAM(<200MB at boot) when a single tab Chromium browser played a youtube video fullscreen for a few minutes. The laptop only has 2GB RAM(usually averages 800MB usage) so this ended up filling up the RAM and I guess was more of a disk I/O/swap slowdown at that point where something like this GPU priority support wouldn't make a difference?

[starshipeleven]

Does this mean less chance of the UI freezing up or stuttering under heavy load(like compiling?).

No because this is for GPU, and imho your issue is unrelated as the GPU isn't the one doing most of the work in an OS just running a GUI and some user pèrograms.

Afaik linux handles pretty well CPU loads already. I can launch multicore compilation on most systems and the GUI will not be affected at all. Very crappy CPUs will be swamped, but I'm looking at Atoms, VIA crap and AMD very low end stuff. Even crappy Core2Duos weren't as bad as that.

What swamps Linux the most is I/O. So using BFQ scheduler, using an SSD disk instead of the mechanical ones (which are rather crappy).

You can also use ionice tool to give lowest I/O priority to your compilation process(es), or nice tool to change CPU priority of your process, and this would probably give you a bigger change than just switch the scheduler.

Also making sure the system isn't swapping at all is recommended. Swapping will make the system stutter, there is no way around it.

[polarathene]

i hate to say this but if you want better performance you need a laptop upgrrade. While you can tweak things some, more RAM for example, the reality is you can only get so much out of a Core2Dou. I hade a similarly equied MBP that suffered similarly, it got to the point nothing ran well on it.

Your only other option is to go with a very light weight Windows manager and play around with the scheduling software. In the end though you only have so much horse power to work with.

By the way im not dismissing the imptovements that can be made through software. The problem is this generation of hardware has ran its course. Developers seldom bither with improvements to such old hardware.

It actually flies really smoothly on the dated hardware, I was quite surprised, I expected KDE to not be a viable option and that I'd have to use XFCE, i3 or something else. It boots into 450MB of RAM usage and I can use 3D effects, wobbly windows, no lag/stutter. Netflix plays smoothly with 720p video. I just have no idea why the plasmashell process ate up close to a GB of memory when youtube(single tab in chromium) had been running a few minutes in fullscreen. It's not chromium, that worked perfectly fine for browsing multiple tabs on websites.

Someone on reddit suggested it could be the kwin feature that makes live thumbnail previews for app switching or when you hover on the taskbar over app icons. Might have leaked memory making unneccessary thumbnails and not discarding them, I'll be disabling that to see if that is the cause. Otherwise this laptop really does perform really well with KDE(Manjaro with zswap and liquorix kernel providing BFQ and and MuQSS + other optimizations).

It rarely exceeds 1GB of RAM usage for casual use(it's just for a family member that likes to browse the web, watch videos, write some documents/email, etc. Nothing intensive, so the 2GB RAM hasn't been an issue usually. Sometimes the CPU gets hit hard with both cores(2.5GHz) at 100%, so it's not too usable during system update of packages.

[polarathene]

No because this is for GPU, and imho your issue is unrelated as the GPU isn't the one doing most of the work in an OS just running a GUI and some user pèrograms.

Afaik linux handles pretty well CPU loads already. I can launch multicore compilation on most systems and the GUI will not be affected at all. Very crappy CPUs will be swamped, but I'm looking at Atoms, VIA crap and AMD very low end stuff. Even crappy Core2Duos weren't as bad as that.

What swamps Linux the most is I/O. So using BFQ scheduler, using an SSD disk instead of the mechanical ones (which are rather crappy).

You can also use ionice tool to give lowest I/O priority to your compilation process(es), or nice tool to change CPU priority of your process, and this would probably give you a bigger change than just switch the scheduler.

Also making sure the system isn't swapping at all is recommended. Swapping will make the system stutter, there is no way around it.

I don't think it was swapping until it had to(1.7/1.9 GB RAM), as mentioned in previous post, the system runs really well, it only really hit a big usability issue with the fullscreen youtube video, not because of the browser RAM usage but because for some reason the plasmashell process went from <200MB RAM to almost 1GB.

It's already using a custom kernel(Liquorix) which has BFQ, MuQSS and other optimizations. The disk though is an obvious bottleneck, until the system is not having issues that aren't related to the slow disk I/O(USB 2.0 stick), the user will continue to use Windows on their HDD(IDE), it almost got to the point that they were confident to switch from Windows, which doesn't run that great, but still met their needs of being able to watch youtube fullscreen without crapping out.

[polarathene]

Not really, none of this is related to the GPU and I doubt that X11 is the problem here.

You can try if changing CPU governor helps. I have less UI stutters with 'schedutil'.

Check what is currently used:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

If not schedutil then run this:

echo schedutil | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

This will be reset after a reboot.

I noticed in htop this was having about 10% or so higher CPU usage, can't say that governors made too much noticeable difference.

Worked on it all day, realized that hardware acceleration wasn't in use, so that helped bring down CPU usage, it would hover around 30-50% usage vs up to 80% without. Probably higher CPU usage earlier too as youtube was serving up VP9 and r600g(or my gpu at least according to vainfo) doesn't support VP9 decoding, used h264ify extension to get h264 content instead. Enabling hardware accel needed some changes in chrome://flags as well as patched build as the support is yet to be merged to chromium yet(only on ChromeOS, and the feature to be merged is only for intel-vaapi apparently, no mention of radeon/amd vaapi support).

Monitored GPU perf with radeontop, 80-95MB of vRAM is used prior to launching Chromium, for 720p video gets up to 175MB vRAM, around 200MB if fullscreen, and higher still when I enabled some other GPU/hardware accel flags for improving perf, disabled those as vRAM tops out at 256MB. GPU activity is only about 10-20% during playback.

Still some playback issues where it'd freeze for a second or two. CPU and GPU were ok, as was RAM(about 1-1.3GB for the system out of 2GB). Turns out Chrome was writing to disk several MB often, some times peaking too high for the 32GB USB 2.0 stick that is being used for the OS. I was able to pinpoint the process/pid but not what files were being written too(I lack the knowledge there I guess), I used `iotop -b -n 2 -d 30 -a -o` which 30 seconds later accumulates disk I/O and outputs the processes with their read/write that occurred in the time period. Chrome would average around 6MB to 22MB.

Used some cmdline flags to go with the app launch, but --disk-cache-dir doesn't seem to output anything to the /tmp location I provided, set the cache size to 100MB max. I have profile-sync-daemon active to move the browser profile into tmpfs with overlayfs to minimize I/O, it periodically every hour uses rsync to move any changes to disk. After setting that up, I don't seem to have any issues with 720P fullsreen video anymore now which is good

[trek]

Does this mean less chance of the UI freezing up or stuttering under heavy load(like compiling?). I have an old laptop with only 2 cores, no hyper threading, if both cores are at full load like when compiling packages, it's not too responsive/smooth to use. Even moving windows around or clicking UI buttons can slow to a crawl.

as already mentioned, you should run heavy jobs with the nice command:

nice make