Category Archives: Linux

Orange Pi RV2 – A $30+ RISC-V SBC powered by Ky X1 octa-core SoC with a 2 TOPS AI accelerator

Posted on by
While the Orange Pi RV RISC-V SBC introduced at the Orange Pi Developer Conference 2024 last year is yet to be launched (should be up in a few days), the company has just launched the Orange Pi RV2 powered by the Ky X1 octa-core RISC-V SoC with a 2 TOPS AI accelerator, up to 8GB LPDD4X, optional eMMC flash moduyle, two M.2 sockets for storeage, dual gigabit Ethernet, WiFi 5, and more.

DRM User-Space API For Apple Silicon Graphics Posted For Review

Posted on by
While the Asahi AGX Gallium3D and Honeykrisp Vulkan drivers continue to be developed within mainline Mesa for supporting OpenGL and Vulkan with Apple Silicon M1/M2 SoCs, the necessary Direct Rendering Manager (DRM) kernel driver has yet to be upstreamed. But hitting the mailing list today is a patch getting the user-space API (UAPI) with more eyes on as the precursor to the actual kernel driver that is currently held up by waiting on Rust kernel abstractions to be upstreamed…

Python tail-call speedup based on LLVM regression

Posted on by

The Python project’s recent switch to a tail-calling interpreter may not provide as large a speed advantage as initially thought. A blog post from Nelson Elhage gives the details. In short, switching to a tail-call-based interpreter accidentally works around an unfixed regression in LLVM 19. On other compilers, the performance benefit (while still present) is more moderate.

When the tail-call interpreter was announced, I was surprised and impressed by the performance improvements, but also confused: I’m not an expert, but I’m passingly-familiar with modern CPU hardware, compilers, and interpreter design, and I couldn’t explain why this change would be so effective. I became curious – and perhaps slightly obsessed – and the reports in this post are the result of a few weeks of off-and-on compiling and benchmarking and disassembly of dozens of different Python binaries, in an attempt to understand what I was seeing.

[$] Capability analysis for the kernel

Posted on by
One of the advantages of the Rust type system is its ability to encapsulate
requirements about the state of the program in the type system;
often, this state includes which locks must be held to be able to carry out
specific operations. C lacks the ability to express these
requirements, but there would be obvious benefits if that kind of feature
could be grafted onto the language. The Clang compiler has made some
strides in that direction with its thread-safety
analysis feature; two developers have been independently working to
take advantage of that work for the kernel.

AMD EPYC 9845 Makes For A Persuasive Upgrade With Performance & Energy Efficiency

Posted on by
With the new AMD EPYC 9005 processors there are SKUs up to 500 Watt with the likes of the EPYC 9965 flagship at 192 cores for Turin Dense cores or 128 Turin classic cores with the EPYC 9755. But for those looking at upgrading from an existing EPYC 9004 series server and bound by the motherboard BIOS support and/or cooling/power capacity, 400 Watts is a sweet spot. Many of the existing platforms designed for EPYC 9004 Bergamo/Genoa(X) and now extended for EPYC 9005 Turin are limited to a 400 Watt TDP. With the prior AMD EPYC 9655 testing I have already shown off the great Zen 5 uplift when maintaining the same core counts as Zen 4, but even sticking to 400 Watts at the top-end is room for more. The EPYC 9845 is AMD’s top-end SKU for 400 Watts or less that allows for 160 dense cores (320 threads) per socket compared to the 128 core EPYC 9754 Bergamo. Effectively the same power level and 25% more — and better (Zen 5C) — cores. Plus with EPYC Turin supporting the new AMD P-State CPU frequency scaling driver there is greater headroom in optimizing for power efficiency if so desired. Here is a look at how the AMD EPYC 9845 delivers a great leap to performance and power efficiency for those looking at a surprisingly robust upgrade from prior generation EPYC 9004.

Intel Preps Xe3’s “Dirty Rect” Feature For Linux 6.15

Posted on by
Along with other exciting Intel kernel graphics driver updates submitted for the upcoming Linux 6.15 merge window, another batch of drm-intel-next code was sent out today to DRM-Next. This pull request is mostly around bug fixing and other low-level work but it does provide a new “dirty rect” feature being introduced with next-gen Intel Xe3 graphics…