xf86-video-ati 18.0 X.Org Driver Released

[leipero]

A bit slow at running the old counterstrike (expected : 100 fps at 1024x768. got slow downs well below 60..). Will try again on Ubuntu 18.04?
Having access to clocks would be nice because perhaps the RAM is set to something low. Otherwise yes it worked.
I could get another GPU, but on "old" desktops like that the more pressing issue is slowly dying hard drives

Old Counter Strike like 1.6 or Source? 1.6 should work just fine, I mean it can work on far worse GPU's hitting locked 100FPS without any FPS drop, Source would be pushing it.

[polarathene]

I don't know about KDE, but for Chromium on HD 4350 hardware acceleration was disabled (last time I've checked = 5+ months ago), simply changing "Override software rendering list" option to enabled in "chrome://flags/" improves performance of the browser a lot (and that PC is used mostly for browser based flash games, all of them working quite well after this is done).

That tip isn't relevant to what I was talking of, it was reporting errors with the driver implementation being incorrect and different workarounds it'd apply or something. Which I was a bit surprised to see as I thought the driver being maintained so long wouldn't be popping up all of that. Didn't seem to cause any noticeable issues though, so no problem with that.

Actual performance was fine apart from 720p video playback. I enabled other hardware accel features like the one you mentioned at one point but I don't think they made that much of a difference to the experience, plus with the youtube video playing fullscreen I was seeing in radeontop about 200MB+ used of vRAM out of the available 256MB, so offloading more to the GPU was putting it close to using up the vRAM which I assume isn't good if it runs out of free vRAM?

I did use a patched version in third party repo to get hardware accel video with vaapi enabled. Chromium will hopefully make the patch officially sometime this year to not require it. That brought down CPU usage by about 20%, and an extensino h26ify to prevent youtube providing VP9 videos which don't seem to have hardware decode on the GPU. So instead of hitting 100% CPU or close to, video playback was about 30-50% CPU across the two cores.

That still wasn't enough though. Turned out the biggest issue for playback issues(audio worked fine but frames would stall/freeze for several seconds), was disk I/O from the browser. The OS was installed to a USB 2.0 stick, writing over 16MB seemed to be a problem and iotop showed chromium would regularly write 6MB over 30 seconds, sometimes even 22MB or more. Offloaded the browser profile and cache to RAM with a helpful package profile-sync-daemon. It would use overlayFS and sync back the difference to disk each hour or when browser was closed or system shutdown. No more issues after this change, works well.

Oh and it's an old laptop, I don't see the GPU being upgraded, I've got a much more powerful desktop system I usually use.

[leipero]

polarathene That makes sense, so GPU isn't a problem on that machine (apart from video RAM, that might be actual RAM shared idk.), but rather CPU and the way OS is installed (USB 2.0 stick instead of internal storage). For example HD 4350 can play 1080p+ videos without breaking a sweat.

[polarathene]

polarathene That makes sense, so GPU isn't a problem on that machine (apart from video RAM, that might be actual RAM shared idk.), but rather CPU and the way OS is installed (USB 2.0 stick instead of internal storage). For example HD 4350 can play 1080p+ videos without breaking a sweat.

Yes, initially CPU usage was higher due to youtube serving VP9 and the lack of hardware accel, even for h264 encoded video(I wasn't aware that browsers still didn't support this, required third party patch for Arch at least). The disk I/O seemed to be the main perf issue, again, I didn't suspect that a browser wrote so much so often at idle on a single tab, offloading to RAM via tmpfs resolved it, probably a non-issue if running off an internal HDD/SSD.