I’ve tried most of the common options (with the notable exception being the vastly overpriced Librem 5). The best option IMO is the OnePlus 6 or 6T (they’re almost identical) running postmarketOS. It is much faster than the PinePhone Pro with way better battery life and has proper modern GPU support (OpenGL up to 4.x, Vulkan). The main thing preventing daily driving the OnePlus 6/6T is that the earpiece audio doesn’t always work for calls and that it won’t wake from sleep when an incoming call comes in. The PinePhones are better to use for voice calling, but slower, lacking many graphics APIs (no Vulkan, limited OpenGL), and have much worse battery life. The camera doesn’t work at all on the OnePlus phones yet, it is starting to work on the PinePhones but the picture quality isn’t all there.

At the moment I have both a OnePlus 6 and 6T, but I have stock Android on the OnePlus 6 and postmarketOS on the 6T. I use the Android one as my daily driver with my primary number SIM but got a second cheap Mint Mobile SIM for the postmarketOS one for experiments and mobile data. I prefer browsing on the postmarketOS phone, and I use it for VPN, SSH access, file management, and some coding on the go which are things Linux phone excels at over Android. I mostly use the Android phone for calls, texts, camera, maps, email (GMail), Discord, and casual browsing. If they fix the earpiece audio issue I would probably be fine daily driving the

Open source NVIDIA drivers (NVK, nouveau, nova) finally being usable for gaming.

Linux phones, postmarketOS

RISC-V CPUs becoming more and more viable

Linux on phones and tablets is a thing. Typing from my Xiaomi Pad 5 Pro running postmarketOS and LibreWolf.

How is the external display connected? I have never seen Freesync over HDMI work. The early implementations were AMD proprietary and the new ones require HDMI 2.1 which has some ridiculous bullshit about not being implemented by open source drivers. HDMI sucks, use DisplayPort if possible. If your laptop doesn’t have a DisplayPort connector, try a USB-C to DisplayPort cable, as usually the type C ports on laptops support DisplayPort alt mode.

Hot dogs

Freddy’s fry sauce, barbecue sauce, teriyaki sauce, honey mustard, cocktail sauce, malt vinegar, cheese sauce

Are you testing this on a Raspberry Pi? The PAN_ prefix seems to indicate this is a configuration for the Panfrost driver (which is the open source driver for ARM Mali GPUs) and the Raspberry Pi does not use an ARM Mali but rather a Broadcom VideoCore GPU, so I don’t see how this would affect the Raspberry Pi.

The only instance I can see this is if a game requires a new Vulkan extension, which wouldn’t need a new kernel but would need a new Mesa version to provide that extension. For the most part, games use established and standardized APIs (OpenGL, Vulkan, Direct3D) to utilize the GPU and as long as the driver implements the APIs used by the game, the driver doesn’t need to continuously update in order to support game updates. On Linux, the driver doesn’t handle Direct3D anyways and an intermediate layer (DXVK or VKD3D) is used to translate Direct3D API calls into the Vulkan API. Vulkan does support extensions which are added every so often to provide new interfaces and the userspace portion of the driver (which is responsible for compiling/translating Vulkan API calls into raw GPU instructions) needs to be updated to support these, but also sometimes these extensions are optional and games can use less optimized code paths to work around missing extensions.

I wish these implementations of secure boot were designed more to protect the SOFTWARE against “theft” than the HARDWARE against “tampering”. Let us wipe the secure boot keys, but in the process erase the firmware (or have the firmware encrypted so that erasing the keys renders it unbootable) and then allow new code to run. Blocking third party firmware on consumer devices is a shit move. It just creates more e-waste when the OEM stops updating it and the community can’t make their own replacement firmware.

Pretty much all ext4 except for a few Windows installs on NTFS.

True, but if you buy a finished product that uses the new chip that has secure boot enabled, you can’t flash your own firmware. From what I gather, the boot keys are burned into OTP memory so they can’t be erased or changed. The chip is permanently locked to that firmware.

The kernel driver is a rather small piece of the overall puzzle though, itps just the pipe that GPU commands are passed through. The bulk of the GPU driver code (and the majority of its impact on performance) is in the userspace components like the shader compiler and the OpenGL/Vulkan libraries. These are closed source.

The exception to this rule is that the kernel driver is responsible for power management and controls the GPU clocks, but as part of opening up the kernel driver NVIDIA made reclocking available for the fully open driver (nouveau/nvk) to use as well which means the performance differences between the two driver stacks are now down to optimizations.

Yeah, NVIDIA will do that to you. That still sounds too low though, are you using the NVIDIA proprietary drivers? I’m not sure Fedora ships NVK yet as it is rather new, I think became mostly usable around Mesa 24.0 earlier this year.

I got a Radeon 7800XT in March and have had no significant issues with it on Arch Linux. The issues I have had were from running the bleeding-edge mesa-tkg-git drivers which are the pre-release development builds, and sometimes things break there (I had a weird issue where red and green got swapped in X11 apps). You have to go out of your way to run those drivers though, stick with the released version in your distro’s repository and you’ll be fine. I can play most games above 100Hz at decent resolution and quality. I have a 4K 144Hz monitor with Freesync but for more demanding games usually need to turn down settings a bit or use resolution upscaling like FSR. I upgraded from an Intel Arc A770 and it was a big performance increase.

AMD (or anything that uses Mesa drivers really) just works out of the box. That pain is unique to NVIDIA.

What are you running it on? I haven’t touched Apex in a while but last time I tried on Linux it was playable (this was probably on my Intel Arc A770). I’ve played BeamNG on my Steam Deck (AMD GPU) and it runs decently too.

Did you wait at all? Slow performance when you first open a game is sort of normal because of shader compilation. It’s a side effect of the translation layer used to run Direct3D games on Vulkan. Once shaders are all compiled the slowdown should go away.

The key thing to note about NVIDIA “open sourcing their driver” is that they only open sourced the kernel portion. I see no intention of opening the userspace portion. GPU drivers have multiple parts. The kernel driver is the low level interface that passes data to and from the hardware while the userspace is what actually handles converting OpenGL, Vulkan, OpenCL, CUDA, etc. calls into GPU commands and that part is where most of the performance impact happens. NVIDIA is not open sourcing the userspace.

That’s why NVK/Nouveau are so important, because it is a fully open stack. It is also part of the Mesa project which encompasses all the open GPU drivers on Linux which makes it more integrated with the Linux graphics stack.

On AMD there is a pro driver that I think is proprietary but nobody uses it for desktop usage or gaming. You might use it if you were doing GPU compute servers on professional cards, but the open source radv driver has the best gaming performance for AMD.

On NVIDIA there is the proprietary driver that consists of out-of-tree module (both open and closed source variants depending on what GPU generation) and the proprietary userspace OpenGL/Vulkan/CUDA driver. Completely separately you have the open source Nouveau kernel and OpenGL driver and NVK Vulkan driver. The proprietary one has better performance in most cases but is broken for Overwatch 2 while NVK runs OW2 smoothly at low settings for me, and that’s my most played game.

And yeah, I am the creator of OpenRGB. Thanks!

Not really a fan of putting secure boot on. The only purpose that serves is locking the customers out of their purchased hardware. Raspberry Pi is clearly not targeting the maker market with those changes, they want that corporate money and are willing to stick the finger to hackers and makers in the process. Can’t make custom firmware if you can’t boot it.