Asahi Linux on M3: installation is open, GPU and sleep are not ready

Asahi Linux has opened installation on M3 Macs. That does not make every supported machine a ready replacement for a daily Linux workstation. The September 6 announcement covers M3, M3 Pro and M3 Max MacBooks and iMacs, behind Expert mode. GPU and full display-controller support remain unfinished, with sleep and HDMI limitations on affected MacBooks. Official announcement

An installation-complete screen is welcome when moving a development environment. Opening the lid in a meeting the next morning is a different test. This release sits between those two milestones.

VLSI Korea view: executing instructions on a chip and qualifying a product workflow are different engineering milestones.

1. Read installation support at the right level

For a kernel or driver developer who already owns an M3 Mac, access to a native hardware experiment is useful. Someone whose day depends on video meetings, external monitors and reliable mobile power management has a different adoption decision. The workload changes the answer even when the machine stays the same.

Separate three layers: an installer recognizes a machine; its required devices function; the actual application uses those devices correctly. Passing the first layer does not establish performance or reliability at the last. This is a recurring platform bring-up problem, rather than a peculiarity of Macs.

Official sources also disagree. The live M3 feature matrix still marks the installer WIP and video decoding “no AV1,” while the dated announcement describes installation and AV1 decoding support. We report that announcement without treating the discrepancy as proof of validation across every application and distribution.

Record the machine, distribution image, kernel, firmware and userspace packages next to any support claim. Those versions make regressions traceable. A release announcement and a continuously maintained matrix serve different purposes; conflicting entries deserve conservative treatment until reconciled.

2. Decoding video is not rendering a desktop

A video decoder produces frames from compressed video. A GPU performs graphics work; a display controller sends the result to the screen. Calling all three “graphics support” hides the missing stage. AV1 support alone says little about readiness for a 3D application or GPU compute workload.

The Linux stateless decoder interface gives userspace responsibility for stream parsing and supplying decoding controls with requests. Hardware presence does not automatically connect every player to that path. The application API and driver interface must also meet.

The August 26 Asahi report describes a VA-API translation layer for AVD, but says it was not then part of Fedora Asahi Remix's default configuration and did not work with Firefox's video sandbox. The installation announcement does not establish that those application-level restrictions have disappeared. Disabling a sandbox is not an adoption strategy.

Visible playback could use software decoding on the CPU. Hardware decoding could still leave additional work in composition or display. Qualification should distinguish the active decode path, dropped frames, CPU usage and power under the same input. This article supplies no measurements from an M3 device.

For Korean SoC and multimedia-IP teams, decoder correctness and end-product playback are separate tests. An IP block can produce correct frames while the browser takes a different path. Blaming the silicon alone can miss a software-interface failure.

3. Shared memory still needs a shared pixel contract

Unified memory can sound as though it removes every copy. Physical proximity and agreement about what the bytes mean are different conditions. A consumer needs the producer's format, layout and access ordering to match.

Linux's pixel-buffer exchange documentation separates pixel format from modifier: color representation versus memory layout. Participants need a common supported combination; without one, a conversion or copy strategy is required. Even a nonempty intersection does not guarantee every import constraint is satisfied.

This becomes a concrete interface-review question. Can the display side accept the decoder's format, including its compression or tiling? Are stride and offset correct? Finding one matching name in a capability list is less useful than checking the combination for its actual intended use.

The dma-buf documentation treats buffer sharing and asynchronous synchronization together. Consumers must not read unfinished output. Passing a handle, waiting for completion and ensuring CPU cache coherency are distinct responsibilities; grouping them all under “sharing” can leave a test missing.

VLSI Korea view: access to the same memory is not enough. Pixel representation and access ordering must agree too.

Read zero-copy as a claim about a specified buffer-transfer path. It does not mean zero system memory traffic or the disappearance of all composition work. Draw the two stages whose copy is removed, then identify the conversions and measurements that remain.

4. Put a size on one copy

This is a hypothetical buffer-size calculation, not an M3 benchmark. Assume an uncompressed 3840 × 2160 ARGB image at 4 bytes per pixel, no padding, and 60 frames per second. One frame contains 33,177,600 bytes, or approximately 33.18 MB.

Reading or writing those frames in one direction gives 33,177,600 × 60 = 1,990,656,000 bytes per second, approximately 1.99 GB/s. One copy into another buffer adds a read and a write, for approximately 3.98 GB/s of logical data movement. GB means one billion bytes; these are not measured DRAM-bus transactions.

Caches, compression, alignment and actual pixel formats change physical traffic. Real video buffers need not use ARGB. The calculation exposes a scale, not a diagnosed SoC bottleneck. Dividing it by a memory-bandwidth specification would not produce a valid performance-loss estimate.

For adoption testing, vary one condition at a time. Keep the clip and display conditions fixed while changing the path; measure dropped frames, latency and power together. Fewer copies might leave frame rate unchanged if another stage dominates. Unchanged frame rate with lower power could still matter in a mobile product. Both remain hypotheses before measurement.

Institutional investors need the same separation. Better integration could improve usability or support costs, but without users, support expenses and purchase conversion data, it cannot be turned into an Apple revenue or margin estimate. Community platform progress is several evidential steps away from an earnings revision.

5. An AArch64 binary is not the final compatibility test

The next question is application execution. A build targeting the same instruction set does not ensure every existing binary works. Asahi's compatibility documentation describes problems with incomplete 16K-page support, including failures in the loader before program code runs.

16K is 16,384 bytes, or 0x4000. The documentation explains how to inspect ELF LOAD alignment. A library built around 0x1000, or 4K, alignment is a reason to investigate loading and build conditions before benchmarking the CPU. Fixing alignment alone does not certify the entire application.

A chip engineer's practical task is to check tool and library architectures, then qualify the relevant OS and page-size environment separately. Commercial EDA support depends on the vendor's current OS, CPU and licensing requirements. This release is not a support certification for any particular EDA product.

A driver-development experiment and a corporate signoff environment are different purchasing cases. Observability and modification freedom may dominate the former; repeatability, vendor support and prescribed tool versions may dominate the latter. Define the job before comparing costs.

6. Who should evaluate it, and what comes next?

In VLSI Korea's assessment, an existing M3 owner doing platform development now has a reason to evaluate a separate experimental environment. GPU-dependent or mobile daily work has a stronger reason to wait for the required features and application tests. Budget for recovery and qualification time as well as hardware; we have not assigned an invented cash value to those hours.

Read the official partition guidance, understand recovery and prepare backups before installation. This is not a disk-modification tutorial. Removing a working production environment before checking compatibility can make the experiment more expensive.

Product economics & specifications

Share-price context

Share-price chart unavailable: Apple IR and Nasdaq returned no usable historical observations in the checked public pages; a current90-day series and reuse basis could not be verified.

The public XDC 2026 M3 GPU reverse-engineering talk is scheduled for September 29. Its abstract covers userspace and kernel driver porting, but presentation materials are not yet available. A scheduled talk is neither a driver release date nor a performance guarantee.

Over the next 6-12 months, watch completed interfaces rather than a count of feature names: removal of the Expert condition, shipped DCP and GPU support, safe default application video paths, and repeated suspend/resume and display-combination tests. These are our observation criteria, not project delivery promises.

The condition for changing this assessment is concrete: published package versions with the required features and reproducible application tests would strengthen the case for daily use. Today's signal is about what an existing Mac can now help you investigate.

Related reading: VLSI Korea Engineering. Sources and support status checked September 7, 2026. Body diagrams and calculations are explanatory work by VLSI Korea, not device measurements.

Disclosure

This article is provided for informational purposes only and does not constitute a recommendation to buy or sell any security. Figures and factual statements are based on publicly available sources, including company filings, news reports, and market research, and may contain errors in the source material or in the preparation of this article. The author may own shares in companies mentioned. All investment decisions and their outcomes are the reader's responsibility.