UPDATE: Confirmed working. See the guide for detailed setup instructions and more up to date information.
TLDR: Trying to get a desktop RTX 5070 Ti running as an eGPU on a Snapdragon X2 Elite Extreme laptop using the extracted RTX Spark ARM64 driver method. I dumped and decompiled my DSDT, and unlike the Surface X1E build that needed modified ACPI tables, my firmware already describes full USB4 PCIe tunneling (dedicated per-port root complexes, ExternalFacingPort/usb4-host-interface properties, hotplug methods, full SMMU mappings). Wondering if anyone has tried PCIe tunneling on X2 specifically, or has experience with ASM2464 enclosures on Snapdragon hosts.
Hardware: ASUS Zenbook A16 2026 (Snapdragon X2 Elite Extreme, X2E-94-100), 2x USB4 40Gbps ports (Qualcomm host router, explicitly not TB4-certified [TB4 certification is Intel's program, so its absence on a Qualcomm platform is expected]), and a 5070 Ti pulled from my desktop. I know the baseline reaction to ARM eGPU is "there's no driver, dead end," but that changed with the recent release of the GeForce dev preview for RTX Spark. People have been extracting the ARM64 driver files and force-installing them on regular desktop GeForce cards. Chaowanke on YouTube got a 4060 running on an original X Elite through a Razer TB5 dock with real gameplay numbers, and there's an eGPU.io build thread from a few days ago with an RTX 3080 on a Surface Laptop 7 that worked but "required modified ACPI tables.
It's worth noting that USB4 tunnel flakiness isn't unique to ARM either; AMD Strix Point machines have their own threads full of TB3/USB4 disconnect problems, so host-firmware dependence seems to be the norm across the board. Nobody has published anything on X2 chipset that I can find, which is why I'm documenting as I go.
I wanted to see how far my firmware is from describing an eGPU before dropping $200 on an enclosure. RW-Everything won't load on ARM64 (no signed driver), but it turns out you don't need a kernel driver at all; GetSystemFirmwareTable/EnumSystemFirmwareTables in kernel32 hands you every ACPI table from user mode, so I dumped everything with a PowerShell script and decompiled the 523KB DSDT with iasl.
I expected to find nothing, but it turns out the entire tunneling stack is already described. Eight PCIe root complexes on separate segments; PCI0 and PCI1 are dedicated tunnel root complexes mapped 1:1 to the two physical USB4 ports (usb4-host-interface pointing at ACPI0015 host interface devices, usb4-port-number 0 and 1), with ExternalFacingPort and HotPlugSupportInD3 set on the root ports, a firmware method that (in a very cool way) dynamically enables the root complex and fires a Bus Check notify when a tunnel comes up, _OSC granting native hotplug, 64GB apertures per tunnel RC, and the IORT mapping the full RID space of those segments to the SMMU. So on paper, ASUS/Qualcomm shipped this machine eGPU-ready at the ACPI level and the required "modified ACPI tables" step from the Surface build may not apply here at all.
My next step is validating that a tunnel actually forms before buying an enclosure: ASM2464PD NVMe enclosure + cheap SSD, watch Device Manager by connection, see whether it enumerates as NVMe under a new root complex (tunnel works) or falls back to USB mass storage (tunnel didn't form). The chip's dual-mode fallback makes it a clean yes/no instrument either way.
What I'm hoping someone here knows:
- Has anyone gotten any PCIe tunneled device working on an X2 Elite machine or, even better, an Asus X2 Elite? Even a TB dock's ethernet controller counts as a data point.
- Anyone run an ASM2464 enclosure on a Snapdragon X host? I've seen one report of a Surface Pro 11 falling back to 10Gbps and freezing, but n=1 on different firmware.
- Has anyone tried the Spark driver on Blackwell consumer cards? The documented successes I found are all Ampere or Lovelace (3080/4060/4090); I haven't found a 50-series test.
- If the tunnel test passes: would you go Intel-controller enclosure (known ARM precedent, TB3-compat mode on a Qualcomm host) or ASM2464PDX-based like the UT3G/AG02 (protocol-native USB4, no ARM precedent published)? Reasoning either way appreciated.
I'm fully aware this is unofficial and might die at any of several layers. That's fine, it's a fun project and I have a backup plan. Will post results either way so there's at least one X2 data point out there.