Arch eGPU Part 3: >btw I use Arch and i3 on my Thinkpad

Everything was supposed to be perfect. It was supposed to all work. Yet, here I am with another post.

You might remember one of the things I noticed way back in my first post.

NotebookCheck reported that the Blade will drain battery even when plugged in,
and it’s definitely happened to me in eGPU mode, though I’m not sure why...

Well, that came back to bite me - hard. But first, a look back.

KDE Free

I was very ready to accept KDE, but Kwin stuttering with Nvidia drivers was really getting on my nerves. That, combined with the fact that I was already compromising so much by disabling desktop effects and mapping key combinations to tile windows, made me really question why I wasn’t just using a tiling window manager. Did KDE really do so much that I needed to lean on it? To clutter up my ~/.config and dotfiles with k*rc files? To have plasmashell keep segfaulting? To have baloo running rampant on my system? No, I could do better.

Finding a Compositor

The biggest part of switching window managers for this setup was going to be the compositor. I tested:

• Mutter (Gnome/Budgie)
• Muffin (Cinnamon)
• Compton (Any)

Both mutter and muffin had issues with forcing to 100fps. Compton could be forced to 100fps, but whenever anything that used hardware acceleration was on the screen, it would lag when dragging windows around (seems to be an Nvidia thing?). Notably, though, I was able to bypass any need for vsync at the compositor level with ForceFullCompositionPipeline and launched compton with --vsync none, which should remove a lot of issues.

Eventually, I installed i3 (I had a previous configuration to build from on my XPS) and tried to nail down Compton settings. I must have tried for hours, but I couldn’t figure out what was causing the lag. Eventually, I realized I was running Compton mainline (hadn’t been updated in years!), so I installed compton-git. It performed admirably, but dragging windows still caused a bit of lag under heavy load and hardware acceleration. I was ready to chalk it up to the Nvidia driver, but then, for kicks, I installed xcompmgr (which is supposed to be the same as just compton --backend xrender - compton is a fork of this, after all). Surprisingly, xcompmgr performed better than compton, even when hardware acceleration was happening - zero move and resize lag! However, I couldn’t stick with it - it would crash every few minutes. Hopefully the work on compton-git brings performance back to baseline.

i3

Using a tiling window manager allowed me to largely ignore the lag when dragging windows. There’s still some resizing lag on hardware accelerated windows, but I can live with that for now.

My next task was to duplicate the features I’d come to find helpful in KDE in i3:

• Polybar allows me to have a fully customizable taskbar. I recreated the kargos widget from before as a script module that simply shows status when clicked.
• Polybar’s dock allows me to run nm-applet (with gnome-keyring) for fast network settings access.
• I enjoyed the audio switcher built in to plasmashell. I can replicate the functionality by using a pulseaudio script and making the click-right execute pulsemixer in a terminal instead.

Gaming Tests

To try and push the system to its limits, I figured I’d give Overwatch on Lutris a try. Turns out, it just works (after messing with some video settings). Shader cache stuttering aside, it runs very well.

When not docked, Overwatch runs admirably on the 4GB MX150 even through Wine/DXVK - all settings on low, it is extremely playable at 45-60 FPS.

I also tested The Witcher 3 - it may just be my setup, but there was a good amount of input lag. It still ran okay though. Native Linux games and older Windows-only games ran with no hiccups at all.

The Blade Stealth Battery

You may be wondering why I didn’t go too in depth with the gaming tests. Well, I was rudely interrupted by a resurgence of some behavior I touched on in the intro. When put under heavy load, and the dGPU engaged, the Blade Stealth eats more power than what it decides to take in from the 65W USB-C adapter. This happens on both Windows and Linux, and even when testing with an 87W USB-C adapter.

When running Overwatch, battery estimates drop down to about 2 hours - even when plugged in. With the return date fast approaching, I had to decide if all of the hardware problems I’d been experiencing were really worth it.

I finally decided to reach out to Razer Support, and they only suggested I uninstall my Windows battery drivers. I sent them every single report that I could find on the issue and even quoted their warranty policy to them if they decided to rat me out for testing with Linux. They haven’t responded.

Some folks on the linked threads have reported success using third-party adapters, but after testing with the 87W adapter and having no change in the amount of power taken in, (a Kill-a-Watt plugged into both chargers on both OSes shows ~55W bring drawn) I am still skeptical.

So I caved. The inability to control the clocks and fan curves, the loose USB-C ports, the coil+fan whine, and finally the power draw were too many dents in a setup to have. If the power issue ends up getting clarified or fixed by Razer, then maybe I’ll reconsider. I sent back the Blade today.

Moving On With a Heavy Heart

I mentioned that I use a Thinkpad X1 Carbon at work, and while I would grab one in a heartbeat for home, I still wanted to try and make the dGPU route work. Lenovo has another Thinkpad model that fits the bill - the T480s. While I’d definitely be moving to an inferior trackpad (though I actually kind of like having physical trackpad buttons, weird huh), the keyboard should be vastly improved, which I’m grateful for when using a tiling window manager.

The T480s model I picked has:

• A Core i7-8650U (1.9 - 4.2 Ghz, technically a downgrade in clock speed)
• An MX150 (2GB and the Max-Q version, which has a lower clock speed)
• 16GB DDR4 2400Mhz (8gb soldered, with an upgradeable SODIMM slot)
• A M.2 slot (so I can just slam my already configured Arch install back in)
• A 14in WQHD IPS panel (less bright, but higher resolution than the RBS panel)
• A bigger body (13.03" x 8.92" x 0.72" vs 11.99" x 8.27" x 0.58")
• A Thunderbolt port with 2 lanes of PCIe (a downgrade, but shouldn’t matter on eGPU when using an external monitor)
• About the same weight (~2.9 lbs)
• Plenty more ports (probably a good thing for a desktop replacement to have)
• A backlit keyboard (no RGB, darn)

I plan to improve performance on the T480s by applying some community fixes and wisdom. Moving to theoretically better-supported hardware for Linux should also let me have fine-grained control over clocks and fans.

• throttled can undervolt and remove throttling restrictions on Intel Thinkpads. It does this in an extremely janky way, by essentially writing to the CPU power limit and temperature trip point registers every X seconds, but it seems to work.
• I plan to throw some better paste on the chips to improve temps just a little bit.

My next and hopefully final blog post in this series will detail my impressions of the T480s, using it with Linux, applying the fixes I mentioned, and trying out the eGPU with some games. Let’s see if I made the right choice! Until then, thanks for reading!