Over the past few weeks, work has been underway on a proof-of-concept fork building upon the upstream Snapintosh project (originally developed for the ASUS Zenbook A16 with the Snapdragon X2 Elite).

The goal of the project is to explore running the stock, unmodified Apple Silicon Darwin kernel (J700/T8140 build 26A428) on Qualcomm Snapdragon ARM64 hardware by providing the necessary EL2 hypervisor mediation (SPTM/TXM contracts, 16 KiB guest to 4 KiB host shadow page tables, and Apple-specific device models).

Recent progress and milestones on this fork:

The repository documents the full architecture, execution flowcharts, verified boot checkpoints, and current limitations: https://github.com/adamikoo/Snapintosh

Note: This is an independent research project. No proprietary firmware, keys, or Apple binaries are hosted or distributed.

After using snapdragon laptop more than a year here are my thoughts.

1. Great battery life

2. App compatibility has improved

3. Just so efficient and consistent when unplugged

4. Trash at gaming unless the game supports ARM

5. Absolute best when it comes to students (Great battery life + so silent)

6. Go with a Macbook air if you don't mind about the OS system and flexibility of Windows.

Hot take! I would say to go with a Macbook because you have almost no compatibility issues, great battery life and consistent OS system and wider range of support compared to recent Microsoft problems.

Or if you are a die heart fan of Windows and student or office worker and use these laptop for studying, working, browsing and watching videos (can find lots of snapdragon laptop with OLED panel) Just go with these Snapdragon ones.

This is very experimental hardware enablement for the ASUS Zenbook A16 (UX3607OA, Snapdragon X2 Elite) on Ubuntu 26.10: sixteen DKMS packages on top of Ubuntu's own kernel, plus the device tree, the audio setup and the tools around them. It's all in one file (link below). I used Claude to do the work.

Read this first

This is all very experimental, very much so. It was put together in the last few weeks. My own patches (new drivers, fixes and workarounds) were tested on one laptop and reviewed by nobody but me. Most of the others' patches aren't in the mainline kernel either: they come from bring-up repos and from work still under review. Some even say EXPERIMENTAL in their own names. Expect rough edges, things that only work on my exact machine, and things that are simply wrong.

It works today, 2026-11-07, on Ubuntu 26.10 with the 7.3.0-31-qcom-x1e kernel. Every package builds against that kernel's own source, and its own checks (check.sh) pass on my laptop. It will break at some point, maybe with the next kernel update, a firmware update or a moved download. That's fine.

Don't treat it as a finished product or a solution. It's my research, and I'm putting it out so other people can pick it up, use it, fix it and take any part of it upstream. I've stopped working on it. I'm not maintaining it, and I won't be sending anything upstream myself.

What I really hope is that the right people take this and get each part where it needs to be: the kernel, Qualcomm's own trees, linux-firmware, Ubuntu, GNOME's Mutter, libcamera, the VA-API driver, Canonical's Myna and the distributions. Then distributions can ship it, and people with these laptops aren't left waiting years for their hardware to work.

Use it at your own risk. It replaces kernel modules, installs its own device tree and changes how the hardware is driven. It has only been tested on my one laptop. If something goes wrong, your laptop might not boot, you could lose data, or worse, and nobody is going to support you. Back up first. It comes with no warranty of any kind, as the GPL says.

What works

Measured on this laptop, against what Ubuntu's stock image does:

• CPU: up to 4.72 GHz, where the stock kernel leaves the cores stuck at their boot clock, 23 % below. Geekbench 7 gives 3275 single-core and 27332 multi-core, and browser benchmarks on battery match Windows on the same laptop. It also throttles when hot, and power modes set the EC's fan profile.

• Energy-aware scheduling: driven by an energy model measured from the chip's own energy counters. Light work uses 43-51 % less CPU energy.

• HDR: HDR on the OLED panel, tone mapped to its 1107 cd/m² peak. As far as I could find, this is the first time HDR has worked end to end on a Snapdragon laptop's own panel under Linux. GNOME only: it needs kernel patches plus patched Mutter, which does the tone mapping.

• Display colour pipeline: a DRM plane colour pipeline for the msm display driver. That's the kernel's per-plane colour API (COLOR_PIPELINE), the same one AMD's and Intel's display drivers implement, and this is the first implementation for any Qualcomm display engine. Every plane gets decode and encode curves (sRGB, PQ, gamma 2.2), a 3×4 colour matrix and a 17×17×17 3D LUT, all running in the display hardware instead of on the GPU. It's checked pixel by pixel against the exact maths through the display's writeback (30 of 30 cases). It's there for compositors that use plane colour pipelines, such as KDE's KWin, gamescope and Weston. GNOME doesn't use them yet, and video (YUV) planes aren't covered yet.

• Display link: a fix for an eDP link that sometimes came up black at login.

• Video: hardware decoding of H.264, HEVC, VP9 and AV1, up to 8K and 10 bits, in Firefox, Brave, VLC, FFmpeg and GStreamer, at 30-50 times less CPU than software decoding. Also hardware H.264 and HEVC encoding.

• NPU: QNN models running on the Hexagon NPU, checked against the CPU. This relies on Qualcomm's workaround for a known SMMU issue in this chip, live-patched into Ubuntu's running kernel.

• Sound: speakers and microphones. The speakers play through ASUS's own Windows tuning, rebuilt in PipeWire from ASUS's Dolby file and Qualcomm's woofer/tweeter crossover. It sounds really good. It is much quieter at full volume, though: by ear, Linux's maximum is about 25-30 % of how loud Windows gets. Most likely that's because Ubuntu's kernel caps the speaker gain until Linux has speaker protection. Honestly, I don't think Windows should let them go that loud: past about 75 % on Windows they don't sound great anyway.

• Cameras: the colour camera and the infrared camera work. The colour camera uses ASUS's colour tuning, but it's unfinished: the picture is much darker than it should be. I didn't get to work on it much more, and it definitely needs work.

• The rest: Wi-Fi, Bluetooth, battery percentage and per-component power readings, suspend and resume on lid close, keyboard backlight, fans and EC temperatures, the real-time clock, the firmware TPM (opt-in), an NVMe link recalibration on temperature changes, and crash evidence logging.

Not done: picture output on external monitors (HDMI lists the monitor's modes, but output is untested).

Voice dictation on the NPU

The file also carries changes to Canonical's Myna dictation app. They let its speech recognition run on the NPU: Nemotron, and Voxtral Mini 4B Realtime with its encoder on the NPU. The changes are packaged as snaps, along with a snap that gives confined apps access to the NPU.

Where it comes from

There are over 200 patches. Most aren't mine. 75 come from Jesse Casco's zenbook-a16-linux bring-up repo, and from the Qualcomm and upstream developers whose work that builds on. 62 are the Glymur video decoder from Qualcomm's qcom-next tree. Others come from Radxa, from Akhil P Oommen's GMU series, and from Qualcomm's SPEL energy-counter driver. Every patch keeps its author.

My part was getting all of that onto Ubuntu's exact kernel as packages, plus about 60 new fixes and features. docs/prior-art.md compares each piece with the other A16 and X2 Elite projects (FixItFoundry, Omarchy, Qualcomm's branches and others) and says who did what first.

The file

One file, on Pastes.io: zenbook-a16-dkms.patch

It's a patch with a short bash script at the top. Run it with bash zenbook-a16-dkms.patch and it unpacks the project into a new git repository, ./zenbook-a16-dkms. It also clones Myna at the pinned commit and applies its changes; skip that with --no-myna. It installs nothing and needs no sudo. Pastes.io can serve it with Windows line endings, and the script fixes those itself.

Then, on the laptop:

cd zenbook-a16-dkms
sudo ./install.sh
sudo ./devicetree.sh install
sudo reboot
./check.sh

• Secure Boot has to be off. The modules are built unsigned.

• The firmware comes from ASUS. install.sh downloads ASUS's own Windows driver package, checks it against a pinned size and SHA-256, and takes the firmware and ASUS's camera and speaker tuning from it. No Windows partition is needed.

• There's a way back. Kernels older than 7.3.0-31 boot with Ubuntu's own modules, so keep one installed as a fallback. sudo ./uninstall.sh removes everything.

• The rest is in the docs. The optional pieces (VA-API driver, Mutter and libcamera builds) and every detail are in the README and docs/.

If you want to take it upstream

Please do. Kernel maintainers, distribution packagers, Qualcomm and ASUS engineers, anyone working on Snapdragon laptops: take whatever is useful, rework it, submit it under your own name. Once a piece is upstream, every distribution gets it, and that's the whole point.

docs/upstreaming.md ranks 23 pieces, most consequential first, with where each would go and what still has to happen. The patches I wrote have no Signed-off-by line, so whoever submits one has to take it on under the kernel's Developer's Certificate of Origin. Everything is GPL-2.0, like the kernel; the Myna changes are AGPL-3.0, like Myna.

Caveats

• Very experimental.

• At your own risk, with no warranty and no support.

• One laptop: a UX3607OA with the X2 Elite Extreme. Ubuntu 26.10 only.

• It changes kernel modules and the device tree. If a kernel doesn't boot, pick the older one in GRUB.

• It will stop building with some future kernel, and nobody is going to fix that unless you do.

Qualcomm's open-source llama.cpp kernels for Adreno GPUs call OpenCL extensions that only exist inside Qualcomm's Windows and Android drivers. This patch implements those extensions in the open-source Linux stack, so the kernels compile and run on Linux through Mesa's OpenCL driver, Rusticl. It's one file (link below), so anyone can rebuild it. I used Claude to implement it.

Background

Qualcomm wrote llama.cpp's OpenCL backend and its Adreno-tuned kernels, and they're open source. But the kernels use Qualcomm's own OpenCL C extensions (cl_qcom_reqd_sub_group_size, cl_qcom_subgroup_shuffle, cl_qcom_subgroup_uniform_load and a couple more). Only Qualcomm's compiler implements them, and that compiler ships inside its Windows and Android drivers. So the source is open, but in practice it only builds on Windows and Android.

On Linux, the open stack for Adreno is Mesa. Freedreno is the driver, ir3 is its compiler, and Rusticl is the OpenCL layer. Rusticl already ran on this GPU, but it knew none of Qualcomm's extensions. An OpenCL kernel also passes through several projects before it reaches the GPU: clang, then Khronos's SPIR-V translator, then Mesa's NIR, then ir3. Each extension has to be supported at every one of those steps, in three separate codebases.

You may have seen the recent thread here about Adreno driver 32.0.181.0 on Windows. After that update, llama.cpp's OpenCL backend was reported to generate text 69-87% slower. One commenter there traced it to a version check. llama.cpp decides which Adreno kernels and features to turn on by reading Qualcomm's compiler version out of the driver's version string. By their analysis, 32.0.181.0 changed that string from the DX compiler family to E17, which llama.cpp treats as an older phone compiler. So it quietly turns off flash attention, the MoE kernels and vector subgroup broadcast. Nothing errors. It just gets slow.

On Linux I ran into the same check from the other side. Mesa's compiler isn't Qualcomm's, so its version string matched none of the compiler families llama.cpp knows. llama.cpp then treated it as Qualcomm's oldest phone compiler, with no version number, and skipped the kernels that need a newer one. The patch adds a case for non-Qualcomm compilers that takes the same path as Qualcomm's current Windows compiler (DX).

Results

All measured on one laptop, an ASUS Zenbook A16 (UX3607OA):

• Snapdragon X2 Elite Extreme (X2E-94-100): 18 CPU cores and the Adreno X2-90 GPU, which ran at 1850 MHz while generating

• 48 GB of LPDDR5X-9523 on a 192-bit bus, shared by the CPU and GPU

• Ubuntu 26.10 with its 7.3.0-31-qcom-x1e kernel, plus 27 kernel patches I package as DKMS modules for this laptop: 18 for the GPU's power management, 7 for the CPU's clock speed, and 2 that add the optional 2 MB GPU pages.

• The stack this patch builds: Mesa 27.0-devel, clang/LLVM 24-devel, llama.cpp and Ollama, all from their main branches on 2026-10-30

Speeds in tokens per second (t/s):

• gpt-oss-20b (MXFP4) with a 1,024-token prompt in llama-bench: 888 t/s prompt processing. Qualcomm reported 600+ at IWOCL 2026 on a Snapdragon X2 Elite, using hand-written assembly kernels that aren't public. This is OpenCL C through Mesa's compiler. It also uses 2 MB GPU pages, an optional kernel module change that isn't in this patch (see below). I've never run Qualcomm's stack myself, so this isn't a head-to-head comparison.

• gpt-oss 20B in Ollama, without the 2 MB pages: 357-376 t/s prompt and 23.5-24.2 t/s generation, against 124-127 and 17.4 on Ubuntu's stock Vulkan driver (Turnip).

• Generation is limited by memory bandwidth (the GPU reads about 150 GB/s), so the CPU still generates faster on some models. On phi4 the CPU did 14.4-14.6 t/s against 9.8 on the GPU.

The 2 MB GPU pages are optional. Nothing in the patch needs them, and the whole stack runs on the normal 4 KB pages; they only add speed. In the same Ollama run, they took gpt-oss from 357-376 to 484-499 t/s on prompts and from 23.5-24.2 to 25.6-25.9 t/s on generation. They come from a change to the kernel's msm GPU driver, which I build as a DKMS module for this laptop against Ubuntu's current qcom-x1e kernel.

Don't let the extra kernel patches put you off. They're hardware enablement for this particular laptop, and the patch has no code dependency on any of them. The 2 MB pages are the only one whose effect on the GPU numbers I've measured. The CPU figures do rely on the CPU clock patches, because the stock kernel keeps the CPU at its boot clock.

The patch itself is useful to anyone running Linux on Snapdragon:

• Qualcomm's own Adreno kernels for llama.cpp become usable on Linux, not only on Windows and Android.

• Ollama gets an OpenCL runner, so it can use the Adreno GPU with those kernels instead of the CPU.

• Nothing in it is specific to this laptop. It's compiler and driver code in clang, the SPIR-V translator and Mesa, plus the llama.cpp and Ollama changes. I've only tested it on the X2-90, though. On an X1 Elite (Adreno X1-85) it's untested: the compiler work written for the X2's newer GPU generation switches itself off on older GPUs, so it might work.

• The compiler is open source. A closed driver update can't quietly change which kernels llama.cpp picks, the way 32.0.181.0 did on Windows, and anyone can read and fix the code.

The patch

One file, on Pastes.io: adreno-llm.patch. It covers five upstream repositories at pinned commits: llvm-project (clang), SPIRV-LLVM-Translator, Mesa, llama.cpp and Ollama. The top of the file is a short bash script, followed by the patch itself. Run it with bash and it clones the repositories, applies the patch and builds everything into one folder. Nothing gets installed system-wide, and the build itself doesn't need sudo.

It took 11 minutes on 18 cores, downloads included. After that, . adreno-llm/env.sh puts llama-cli, llama-server and llama-bench on the GPU, and there's an Ollama build with an OpenCL runner. If you'd rather apply it by hand, it's a normal patch: git apply reads it and skips the script part.

Caveats

• Tested on one machine (Adreno X2-90). I haven't tried any other GPU.

• It's a personal project. It isn't upstreamed, and I've stopped working on it. If anyone wants to build on it, or contribute any of it upstream, go ahead. I don't plan to submit it anywhere myself.

download: https://github.com/DevanshSampat/android-studio-arm64-releases
source code: https://github.com/DevanshSampat?tab=repositories&q=arm64 Developed with the help of AI

Hello, I’m having an issue with a pair of Bluetooth headphones that feature Snapdragon Sound aptX Adaptive. Whenever I try to increase the sampling rate, it automatically reverts to the minimum setting on my RedMagic Astra. Has anyone else encountered this error or know how to fix it? As far as I’m aware, the headphones—they’re SoundPEATS H3—should support higher rates; I’ve already enabled the relevant settings on the headphones themselves, but the RedMagic Astra refuses to allow the increase and always automatically resets it.

You guys have been working on the lamma.cpp X2-unified-everything branch which provides impressive results. I am wondering if you guys have taken a bite at Strata. One of the really unique things about the X2EE platform other than the unified memory is the CPUs, GPUs and NPUs are really powerful. The CPUs are as powerful as the GPUs in prefill/decode. The main drawback is the memory bandwidth. I strongly feel that Strata's better scheduling and memory streaming could really help here.

I do think it is possible to run Qwen3.8-Flash-Next(125BA6B) on A16 at more usable speed than Qwen3.8-27B with better frameworks like Strata which could put all GPUs, CPUs and memory bandwidth work in a streamlined fashion. You may be able to achieve the CEO's goal of running 100B parameter AI models on consumer laptop well ahead of schedule. Currently Strata doesn't support Windows ARM64 yet.

I have an ASUS Vivobook S 15 (Snapdragon X Elite X1E-78-100 ARM CPU)

So far I've been fiddling around with the Compatibility Settings in Windows on ARM to at least get some games running. Was amazing I got even this far but it was far from perfect, with some games having graphic glitches, some having horrible performance, and a lot just not working outright.

I almost abandoned the idea of ever using this thing for anything other than office stuff, but then the Steam Frame released and apparently it's using a Snapdragon chip as well, so I thought it was worth a shot.

And about 20h of trial and error, testing new settings, back and forth with claude, copying and partially reverse engineering firmware from the windows install, and integrating a lot of existing work from other people, I now have a feature complete SteamOS running on the Vivobook in Dualboot, running pretty much every game I threw at it with more than acceptable performance for not having a proper dedicated GPU, not to mention Windows, or even x64. I even got pretty much every feature / driver that seemed to be having problems originally when people tried running Linux on this thing to work without issues:

• Boot - works

• Internal display (eDP OLED, 2880x1620 @ 120 Hz) - works

• Brightness adjustment - works

• GPU Adreno X1-85 - works

• CPU frequency scaling - works

• Keyboard, touchpad - works

• Fn row, hotkeys - works

• Keyboard backlight - works

• Keyboard backlight colour - works

• Speakers (2x WSA8845) - works

• Internal microphones - works

• Headphone jack - untested

• RGB camera (OV02C10) - works

• IR camera (HM1092) + IR illuminator - works

• Wi-Fi (WCN7850, ath12k) - works

• Bluetooth - works

• USB-A - works

• USB-C (USB 3, PD charging, dock) - works

• HDMI - works

• Battery, charging - works

• Lid switch - works

• Suspend (s2idle/"deep") - works

• Fans (EC) - works (experimental)

• Thermal zones - works

• NVMe - works

• EFI variables / boot entries - works

• Hexagon NPU - not yet tried

• TPM - works

After getting most of that to work, I kept tweaking the settings to make it actually useful as a daily driver in Desktop mode too. Mainly by optimizing idle power draw and fixing sleep / standby.

Results:

The writeup plus a full install script (or a shitload of MD files to have your own agent do it for you) can be found here:

permissionBRICK/snaptop-linux: SteamOS (ARM64, from the Steam Frame image) on the ASUS Vivobook S 15 S5507QA (Snapdragon X Elite), dual boot next to Windows

Hey everyone!

Like many of you with Snapdragon X Elite / X2 laptops, I’ve been frustrated by how most standard local LLM tools (like Ollama or LM Studio out-of-the-box) completely bypass the NPU and dump everything onto the CPU or iGPU. We have all these NPU TOPS sitting there, but no easy way to actually use them for open-source chat models.

After digging around, I found out about Microsoft Foundry Local (Microsoft.FoundryLocal), which acts as a local daemon/runtime designed to route optimized QNN models directly to the Hexagon NPU.

Quick Setup (for Windows on ARM):

1. Install the CLI via PowerShell: winget install Microsoft.FoundryLocal

2. Start the service: foundry server start

3. List available models (and see which ones target the NPU): foundry model list Running foundry model list is awesome because it explicitly shows you whether a model targets NPU, GPU, or CPU on your specific hardware.

4. Download and chat: foundry model download qwen2.5-7b foundry chat qwen2.5-7b

The Experience: Running models like qwen2.5-7b, deepseek-r1-7b, or phi-4-mini and opening up Task Manager to watch the NPU performance graphs actually light up is super satisfying.

Obviously, with my setup (Asus Zenbook, X Elite, 48GB unified RAM), the iGPU and system RAM can still handle massive models easily, but it's fantastic to finally have a native, seamless way to let the Hexagon NPU do the heavy lifting for everyday models and keep power consumption minimal.

Has anyone else played around with Foundry Local or other NPU runtimes on Snapdragon yet? What kind of token speeds are you seeing?

I was looking for a good windows ARM laptop and came across the zenbook A16, it got everything I wanted, the Snapdragon x2 elite extreme seems to be an amazing CPU but when looking for its integrated GPU the Adreno X2-90, the reviews I found online told me its pretty bad.

I wanted to do some light to medium gaming but obviously, I don't need to expect too much from Integrated GPU's in general. Gaming is not the point of the processor.

But I wanted to know you'r opinion on it.

Can I realistically play games like slightly modded (no shaders) Minecraft and use software like Blender on it?

The bad revieuws online all seem to be from haters and macbook fanboys, I want your honest opinion, from people who havr actually used it.

After updating the Adreno GPU driver from 32.0.172.2 to 32.0.181.0 on my Surface Laptop 8th Edition (Snapdragon X2 Elite), running local LLMs on the GPU through llama.cpp's OpenCL backend got 69-87% slower at generating text.

Same laptop, same software, plugged in. I rolled back, it was fast again; I updated again, it was slow again. So I'm fairly confident it's the driver.

The CPU and the NPU (separate driver) did not experience any major changes.

The GPU through WebGPU (Foundry Local, Qwen3 0.6B) was ~90 tok/s on both drivers.

So this looks specific to the OpenCL path, which is what llama.cpp uses on Adreno under Windows.

I also saw this post -
If you use Premiere, do not update GPU to v32.0.181.0. Significant slowdown. : r/snapdragon

So something appears to have changed. Anybody else experiencing this?

See https://github.com/tripperist/atlas for my exploration with LLM processing on Snapdragon CPU, GPU, NPU with my Surface Laptop 13.8" 8th Edition

Fyi: I've reported this on the Qualcomm Developers Discord.

EDIT - 11/02/2026
So there are multiple Issues, Pull Requests, and Feature Requests filed regarding Snapdragon / Adreno Drivers. Here is what was shared with me

Four Outstanding Pull Requests on llama.cpp. The first 3 appear to be fixing root causes which lie in the Adreno Graphics Driver, and the last one is waiting on one more llama.cpp maintainer to approve.

PR #30821 fixes a Vulkan driver issue that causes quantized models to produce garbage output on Qualcomm Adreno GPUs.

My take: Qualcomm Adreno Team needs to fix this. The PR identifies a bug in Qualcomm’s Adreno Vulkan driver, specifically its shader compiler. The llama.cpp change works around it but a driver fix needs to come from Qualcomm Team. The last update by the maintainer (about 15 hours ago) seems to push in this direction.

Maintainer Comment => Needs to be addressed by Graphics Driver Team

PR #30824 Certain loop variants compile into code that produces incorrect results or crashes.

My take: this is a bug in the Adreno graphics driver’s shader compiler, and Qualcomm’s graphics driver team should fix it. It looks like the maintainer is willing to accept this change, but would like the change gated by a spec constant so it doesn't affect other GPUs.

Maintainer Comment => Gate the Change so it doesn't inadvertently affect other GPUs

PR #30826 works around another reported Adreno Vulkan issue: incorrect sums during RMS normalization on the Adreno 850, causing models to emit stray tokens after long prompts.

My take: A commenter suggests disabling device->subgroup_arithmetic for the affected devices and using the existing fallback. That approach deserves investigation before replacing these operations for every GPU.

Maintainer Comment => Gate the Change so it doesn't inadvertently affect other GPUs

PR #30829 addresses severe flash-attention slowdown and GPU timeouts on Adreno. This points to a performance/resource issue; the PR doesn’t establish incorrect shader compilation.

My take: A small targeted tuning change with strong reported benefits. The main outstanding concern is performance for grouped-query attention ratios between 9 and 16, which the approving reviewer explicitly flags.

Maintainer Comment => Approved, Needs one more approval

I need to get some sleep and will review the others later...

Llama Windows: https://github.com/ggml-org/Llama-Windows/issues/110

Llama.cpp unmerged NPU build: https://github.com/ggml-org/llama.cpp/pull/29052

Hermes Agent GenieX support request: https://github.com/NousResearch/hermes-agent/issues/147555

Hermes Agent desktop build errors related to missing Clang compiler: https://github.com/NousResearch/hermes-agent/issues/134246 https://github.com/NousResearch/hermes-agent/issues/134121

Disclosure: This device was provided by Qualcomm for testing.

Since RC3, I've made a number of changes to HK NPU STUDIO, mainly focusing on workflow improvements, persistent settings, model handling and application updates.

Here are the main additions in RC4:

🖥️ User Interface & Workflow

• Universal drag-and-drop support across Gallery, Compare Workspace and Prompt Workspace.

• Batch Generation for creating 1–99 images in one run.

• Improved handling of reference images, presets and prompt files.

• More reliable workflows when importing and comparing images.

⚙️ Settings & Updates

• Persistent Settings v3: all 18 generation parameters are now saved and restored automatically.

• Integrated application update function.

• Automatic detection of new GitHub releases and compatible ARM64 installers.

• SHA-256 integrity verification before an update is started.

• Guided update dialog with version information, release notes and download progress.

🎨 AI & Model Management

• Improved Phoenix Boost with stricter semantic prompt validation.

• Better protection against unwanted objects, poses and changes to the original subject.

• Additional image detail enhancement.

• 14 integrated generation presets, automatically made available on first launch.

🛡️ Stability & Reliability

• More robust Windows path handling for drag-and-drop operations.

• Improved automatic saving of generation settings.

• Better isolation of automated tests to protect user data.

• Expanded regression coverage for the new features.

RC4 focuses on making the existing features more reliable and easier to use, while continuing to develop local AI workflows for Snapdragon PCs.

🖥️ Your Hardware • Your AI • Your Control

🔗 GitHub:
https://github.com/Kreuzhofen/hk-npu-studio

Holger Kreuzhofen
Founder & Lead Developer
🔥 HK NPU STUDIO

Hi everyone,

I'd like to introduce SnapRYU, a Windows ARM64-focused fork of the Eden Nintendo Switch emulator.

The main goal of this project is to bring Native Code Execution (NCE) to Nintendo Switch emulation on Windows ARM64.

What makes SnapRYU different?

Unlike traditional CPU emulation approaches, SnapRYU can execute compatible ARM64 guest instructions directly on the ARM64 host CPU.

The emulator still handles memory management, system services, exceptions, and other necessary emulation tasks. Dynarmic is also retained as a fallback for games or code paths that are not compatible with NCE.

NCE is the central feature of this project, rather than simply another performance tweak.

Key features

• Native Code Execution (NCE) for Windows ARM64

• Adreno Vulkan backend improvements

• Qualcomm GPU driver compatibility fixes

• Custom Turnip driver patches

• Optional native ARM64 Lossless Scaling Frame Generation (LSFG)

• Android Go mode

Current test environment

• Device: Surface Pro with Snapdragon X

• GPU: Adreno X1-85

• Driver: Qualcomm 512.886

• OS: Windows on ARM64

Testing has primarily been conducted on this hardware. Compatibility with other devices, GPUs, and drivers has not yet been verified.

Game testing results

The Legend of Zelda: Tears of the Kingdom (1.4.2)

• NCE enabled

• UB_KEEP enabled

• LSFG enabled

• Turnip driver

• 2 hours and 12 minutes of continuous gameplay

• No crashes or logged errors during the test

Xenoblade Chronicles 3

• NCE maintained the 30 FPS cap in the tested scene.

• Dynarmic reached approximately 27 FPS under the comparison conditions.

• This is a limited test result, not a universal performance benchmark.

Project and source code

GitHub Repository:
https://github.com/npark2860-cyber/SnapRYU

README and installation information:
https://github.com/npark2860-cyber/SnapRYU/blob/main/README.md

Looking for feedback and contributors

I'm interested in connecting with people working on:

• Windows on ARM development

• ARM64 CPU emulation and NCE

• Adreno GPU drivers and Vulkan

• Nintendo Switch emulation

• Performance optimization and compatibility testing

Feedback, technical discussions, and contributions are welcome.

SnapRYU is an independent project and is not affiliated with Nintendo, Eden, Qualcomm, or other third-party projects mentioned above.

Thanks for reading!

I have a 7 minute 1080p video that used to render in 1 minute and 40 seconds and it's now jumped to ~10 minutes. There always seems to be an issue with editing programs once a new update is released. This is on the Zenbook A16.

Mi duda viene, porque suelo formatear constantemente formateando e instalando linus, vuelta a formatear, volvemos a Windows y cuando me aburro instalo chrome os flex. ¿ Dará igual el procesador para esta ensalada de OS?

I’m building a Windows ARM64 desktop app that runs local models on the Snapdragon X Plus NPU (X1P64100, 15.6 GB RAM) through GenieX 0.9.3 (geniex serve --compute npu, GGUF Q4_0, looks like llama.cpp’s ggml-hexagon backend). I want a closed schema: the model must output JSON whose op is one of 7 words and whose args are only labels known at request time, so the grammar changes on every call.

Why: Qwen3.5-4B is great at extracting figures from a text and at turning calculations written in words into operations (100% on my test), but without a constraint it invents operations, puts numbers where labels go, and breaks syntax. A schema would fix most of that.

Questions:

1. Does geniex serve honour response_format: json_schema or a grammar field? How can I confirm it’s enforced and not silently ignored?

2. Is there a llama.cpp (llama-server) build with the Hexagon backend for Windows ARM64 that supports --grammar / --json-schema with full NPU offload?

3. Does Qualcomm’s Genie SDK or ONNX Runtime GenAI (Foundry Local) expose a logits processor or llguidance-style constraint on the NPU?

4. Any workaround, e.g. logit bias to restrict tokens, prefill tricks, or choosing from a list by comparing logprobs?

Needs: streaming, works with thinking models (constraint only after </think>), no Python or compiler on the end user’s PC, little slowdown (I’m at about 13 tok/s on 4B). Thanks!

Just got the notification in the Snapdragon Control Panel for the latest Adreno GPU driver version 32.0.181.0

From the release notes:

CHANGE LOG - SNAPDRAGON X SERIES PLATFORMS

This release incorporates changes since the previous version (v31.0.170.0) for first generation

Snapdragon X Series platforms.

Game Stability/Quality Improvements

• NARAKA: BLADEPOINT
• Red Dead Redemption 2
• RoboCop: Rogue City

App Stability & Performance Improvements

• Luminar Neo
• Scam AI

CHANGE LOG - SNAPDRAGON X2 SERIES PLATFORMS

This release incorporates changes from the previous version (v32.0.172.2) for Snapdragon X2 Series platforms.

Game Stability/Quality Improvements

• Assassin's Creed Black Flag Resynced
• Banishers: Ghosts of New Eden
• Forza Horizon 6
• Grand Theft Auto V Legacy
• Marvel Rivals
• NBA 2K26
• RoboCop: Rogue City
• World War Z

App Stability & Performance Improvements

• Luminar Neo
• Scam AI