Faster framebuffer landing in Linux 5.18
Code to speed up software framebuffer operations — which is all you get if you're running a Raptor family system without a GPU through the on-board BMC graphics — is due to land in the upcoming 5.18 kernel's merge window later this month. In component commits, the developer cites as much as a 25% improvement in some operations. Much of this gain seems due to just second-guessing the compiler: using the existing high performance memset/memcpy operations (and on OpenPOWER, these take full advantage of the SIMD capabilities in our CPUs) instead of relying on the compiler to auto-vectorize, and manually unrolling loops. This will still be slower than a GPU, and the Libre-SoC project aims to fill that gap with a libre alternative, but for those of us (like me) running a Raptor system "naked" with onboard hardware, this is very welcome news. We'll look at some of the other Power-specific and Power-adjacent changes in 5.18 later this month when the merge window closes.
I haven’t done much manual kernel recompilation since my undergraduate days with Slackware, but I’m thinking about the future once my Power9 kit finally gets here. Since I don’t expect 4K page sizes to be supported by the default kernel, what’s the best procedure for recompiling and installing a 4K page kernel based on Fedora’s (or Ubuntu’s) defaults? Is there currently a good resource that walks through that?
ReplyDeleteFollowing the basic notion here https://kernelnewbies.org/KernelBuild , it's a single config line change, setting CONFIG_PPC_64K_PAGES=n . This thread https://forums.raptorcs.com/index.php?topic=200.0 might give you a little more detail.
DeleteMostly I’m just wondering about the best way to download the distribution-specific kernel source (as I’d downloaded from kernel.org for Slackware), then load defaults, hunt for the 64KB page variable (which you were nice enough to name - thank you!), then build. I will be better able to figure this out once I’ve got the hardware in hand - here’s hoping some love comes PPC64LE’s way in the amdgpu driver this year.
DeleteI don't know about Ubuntu, but Fedora's source can be pulled from fedpkg: https://fedoraproject.org/wiki/Building_a_custom_kernel
DeleteHowever, they don't modify it much that I know of (Dan could confirm this), so when I was building my own kernels I just used their config file and the vanilla source tarball.
Kernel 5.10.101, commit 5234de6c797565815ece9321b1dfe2e6732b5090
Deletedrm/amdgpu: Set a suitable dev_info.gart_page_size
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.101
I'm rooting for Libre SOC to make BE viable again. I can just go and get an HD 6970 and swap it in to boot into BE, but it'd be nice to have hardware that's brand new and you don't have to worry about it dying or becoming incompatible with future standards.
ReplyDeleteI'm under no impression that it'll overtake LE, but a 64K BE system would be cool to have, even if it's not really that different in any meaningful way. I may pick up a Power Mac G4 hackintosh one day and replace the hardware with a Blackbird... I'd definitely use it as a big endian only computer if I ever do.