TinyComputers.io (Posts about ryzen ai)

Upgrading ROCm 7.0 to 7.2 on AMD Strix Halo (gfx1151)

A.C. Jokela — Wed, 18 Feb 2026 16:00:00 GMT

Introduction

If you're running AMD's Strix Halo hardware -- specifically the Ryzen AI MAX+ 395 with its integrated Radeon 8060S GPU -- you already know the software ecosystem is a moving target. The gfx1151 architecture sits in an awkward spot: powerful hardware that isn't officially listed on AMD's ROCm support matrix, yet functional enough to run real workloads with the right driver stack. When ROCm 7.2 landed in early 2026, upgrading from 7.0.2 was a priority. The newer stack brings an updated HSA runtime, a refreshed amdgpu kernel module, and broader compatibility improvements that matter on bleeding-edge silicon.

This post documents the complete upgrade procedure from ROCm 7.0.2 to 7.2 on a production Ubuntu 24.04 system. It's not a theoretical exercise -- this was performed on a live server running QEMU virtual machines and network services, with the expectation that everything would come back online after a single reboot.

AMD's official documentation states that in-place ROCm upgrades are not supported. The recommended path is a full uninstall followed by a clean reinstall. That's exactly what we did, and the entire process took about 20 minutes of wall-clock time (excluding the reboot).

System Overview

The target system is a Bosgame mini PC running the Ryzen AI MAX+ 395 APU. If you've read the earlier review of this hardware, you'll be familiar with the specs. For context on this upgrade, here's what matters:

Hardware

CPU: AMD Ryzen AI MAX+ 395, 16 cores / 32 threads, Zen 5
GPU: Integrated Radeon 8060S, 40 Compute Units, RDNA 3.5 (gfx1151)
Memory: 32 GB DDR5, unified architecture with 96 GB allocatable to GPU
Peak GPU Clock: 2,900 MHz

Software (Pre-Upgrade)

OS: Ubuntu 24.04.3 LTS (Noble Numbat)
Kernel: 6.14.0-37-generic (HWE, pinned)
ROCm: 7.0.2
amdgpu-dkms: 6.14.14 (from repo.radeon.com/amdgpu/30.10.2)
ROCk Module: 6.14.14

Running Services

The system was actively serving several roles during the upgrade:

Five QEMU virtual machines (three x86, two aarch64)
A PXE boot server (dnsmasq) for the local network
Docker daemon with various containers

None of these services are tied to the GPU driver stack, so the plan was to perform the upgrade and reboot without shutting them down first. The VMs and network services would come back automatically after the reboot.

Why Upgrade

ROCm 7.0.2 worked on this hardware. Models loaded, inference ran, rocminfo detected the GPU. So why bother upgrading?

Three reasons:

Driver maturity for gfx1151: The amdgpu kernel module jumped from 6.14.14 to 6.16.13 between the two releases. That's not a minor revision -- it represents months of kernel driver development. On hardware that isn't officially supported, newer drivers tend to bring meaningful stability improvements as AMD's internal teams encounter and fix issues on adjacent architectures.
HSA Runtime improvements: ROCm 7.2 ships HSA Runtime Extension version 1.15, up from 1.11 in ROCm 7.0.2. The HSA (Heterogeneous System Architecture) runtime is the lowest layer of the ROCm software stack -- it handles device discovery, memory management, and kernel dispatch. Improvements here affect everything built on top of it.
Ecosystem alignment: PyTorch wheels, Ollama builds, and other ROCm-dependent tools increasingly target 7.2 as the baseline. Running 7.0.2 was becoming an exercise in version pinning and compatibility workarounds.

The Kernel Hold: Why It Matters

Before diving into the procedure, a note on kernel management. This system runs the Ubuntu HWE (Hardware Enablement) kernel, which provides newer kernel versions on LTS releases. At the time of this upgrade, the HWE kernel was 6.14.0-37-generic. The upstream kernel had already moved to 6.17, but we didn't want the ROCm upgrade to pull in a kernel that AMD's DKMS module might not build against.

The solution is apt-mark hold:

sudo apt-mark hold linux-generic-hwe-24.04 linux-headers-generic-hwe-24.04 linux-image-generic-hwe-24.04

This prevents apt from upgrading the kernel meta-packages, effectively pinning the system to 6.14.0-37-generic. The hold was already in place before the upgrade and remained untouched throughout. After the upgrade, we confirmed it was still active:

apt-mark showhold

linux-generic-hwe-24.04
linux-headers-generic-hwe-24.04
linux-image-generic-hwe-24.04

If you're running Strix Halo or any other hardware where kernel compatibility with amdgpu-dkms is uncertain, kernel holds are essential. A kernel upgrade that breaks the DKMS build means no GPU driver after reboot.

Upgrade Procedure

Step 1: Uninstall the Current ROCm Stack

AMD provides the amdgpu-uninstall script for exactly this purpose. It removes all ROCm userspace packages and the amdgpu-dkms kernel module in a single operation:

sudo amdgpu-uninstall -y

This command removed approximately 120 packages, including the full HIP runtime, rocBLAS, MIOpen, MIGraphX, ROCm SMI, the LLVM-based compiler toolchain, and the Mesa graphics drivers that ship with ROCm. The DKMS module was purged, which means the amdgpu kernel module was removed from the 6.14.0-37-generic kernel's module tree.

After the ROCm stack was removed, we purged the amdgpu-install meta-package itself:

sudo apt purge -y amdgpu-install

This also cleaned up the APT repository entries that amdgpu-install had configured in /etc/apt/sources.list.d/. The old repos -- repo.radeon.com/amdgpu/30.10.2, repo.radeon.com/rocm/apt/7.0.2, and repo.radeon.com/graphics/7.0.2 -- were all removed automatically.

Step 2: Clean Up Leftover Files

The package removal was thorough but not perfect. A few leftover directories remained in /opt/:

ls /opt/ | grep rocm

rocm-7.0.0
rocm-7.0.2
rocm-7.9.0

The rocm-7.0.0 directory was from a previous installation attempt. The rocm-7.9.0 was from an earlier experiment with a release candidate build. The rocm-7.0.2 directory contained a single orphaned shared library (libamdhip64.so.6) that dpkg couldn't remove because the directory wasn't empty. All three were cleaned up manually:

sudo rm -rf /opt/rocm-7.0.0 /opt/rocm-7.0.2 /opt/rocm-7.9.0

It's worth checking for stale ROCm directories after any uninstall. They consume negligible disk space but can confuse build systems and scripts that scan /opt/rocm* for active installations.

Step 3: Install the ROCm 7.2 Installer

AMD distributes ROCm through a meta-package called amdgpu-install. Each ROCm release has its own version of this package, which configures the appropriate APT repositories. The 7.2 installer was downloaded directly from AMD's repository:

cd /tmp
wget https://repo.radeon.com/amdgpu-install/7.2/ubuntu/noble/amdgpu-install_7.2.70200-1_all.deb
sudo apt install -y ./amdgpu-install_7.2.70200-1_all.deb
sudo apt update

After installation and apt update, three new repositories were active:

https://repo.radeon.com/amdgpu/30.30/ubuntu noble -- the kernel driver and Mesa components
https://repo.radeon.com/rocm/apt/7.2 noble -- the ROCm userspace stack
https://repo.radeon.com/graphics/7.2/ubuntu noble -- graphics libraries

The version numbering can be confusing. The amdgpu-install package version is 30.30.0.0.30300000-2278356.24.04, which maps to the amdgpu driver release 30.30. The ROCm version is 7.2.0. These are different version tracks that AMD maintains in parallel.

Step 4: Install ROCm 7.2

With the repositories configured, the actual installation was a single command:

sudo amdgpu-install -y --usecase=graphics,rocm

The --usecase=graphics,rocm flag tells the installer to include both the Mesa graphics drivers and the full ROCm compute stack. This is the right choice for a system that needs both display output and GPU compute capabilities.

The installation took approximately 10 minutes and included:

amdgpu-dkms 6.16.13: The kernel module, compiled via DKMS against the running kernel
Full ROCm 7.2 stack: HIP runtime, hipcc compiler, rocBLAS, rocFFT, MIOpen, MIGraphX, RCCL, ROCm SMI, ROCProfiler, and dozens of other libraries
Mesa graphics: Updated EGL, OpenGL, and Vulkan drivers from the amdgpu Mesa fork
ROCm LLVM toolchain: The LLVM-based compiler infrastructure that HIP uses for kernel compilation

The DKMS build is the critical step. During installation, DKMS compiled the amdgpu module against the kernel headers for 6.14.0-37-generic. The output confirmed a successful build:

depmod...
update-initramfs: Generating /boot/initrd.img-6.14.0-37-generic

The initramfs was regenerated to include the new module, ensuring it would be loaded at boot.

Step 5: Verify DKMS

Before rebooting, we confirmed the DKMS status:

dkms status

amdgpu/6.16.13-2278356.24.04, 6.14.0-37-generic, x86_64: installed
virtualbox/7.0.16, 6.14.0-36-generic, x86_64: installed
virtualbox/7.0.16, 6.14.0-37-generic, x86_64: installed
virtualbox/7.0.16, 6.8.0-100-generic, x86_64: installed

The new amdgpu module (6.16.13) was built and installed for 6.14.0-37-generic. Note that it only built for the currently running kernel, unlike VirtualBox which had modules built for older kernels as well. This is expected -- DKMS builds against available kernel headers, and the old kernel headers for 6.14.0-36 and 6.8.0-100 were still present from earlier installations.

Step 6: Reboot

sudo reboot

The server came back online in approximately 50 seconds.

Post-Reboot Verification

rocminfo

The first check after reboot was rocminfo, which queries the HSA runtime for available agents:

rocminfo

ROCk module version 6.16.13 is loaded
=====================
HSA System Attributes
=====================
Runtime Version:         1.18
Runtime Ext Version:     1.15
...
==========
HSA Agents
==========
Agent 1: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (CPU)
Agent 2: gfx1151 (GPU)
  Marketing Name:          AMD Radeon Graphics
  Compute Unit:            40
  Max Clock Freq. (MHz):   2900
  Memory Properties:       APU
  ISA 1: amdgcn-amd-amdhsa--gfx1151
  ISA 2: amdgcn-amd-amdhsa--gfx11-generic

Key observations:

ROCk module 6.16.13: The new kernel module loaded successfully.
Runtime Ext Version 1.15: Upgraded from 1.11 in ROCm 7.0.2.
gfx1151 detected: The GPU was recognized with its correct ISA identifier.
gfx11-generic ISA: ROCm 7.2 also exposes a generic gfx11 ISA, which allows software compiled for the broader RDNA 3 family to run on this device without gfx1151-specific builds.
APU memory: The memory properties correctly identify this as an APU with unified memory.

ROCm SMI

rocm-smi

Device  Node  Temp    Power     SCLK  MCLK     Fan  Perf  VRAM%  GPU%
0       1     33.0C   9.087W    N/A   1000Mhz  0%   auto  0%     0%

The GPU was visible and reporting telemetry. The 0% VRAM reading is expected on an APU -- rocm-smi reports dedicated VRAM usage, but on a unified memory architecture, GPU memory allocations come from system RAM and aren't reflected in this counter.

ROCm Version

cat /opt/rocm/.info/version

7.2.0

DKMS

dkms status

Confirmed amdgpu/6.16.13 remained installed for 6.14.0-37-generic after reboot.

PyTorch Validation

With the driver stack verified, the next step was confirming that PyTorch could see and use the GPU. ROCm 7.2 ships with prebuilt PyTorch wheels on AMD's repository.

Installing PyTorch for ROCm 7.2

We set up a Python virtual environment and installed the ROCm-specific wheels:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip

The PyTorch wheel for ROCm 7.2 requires a matching ROCm-specific build of Triton. Both are available from AMD's manylinux repository. The order matters -- Triton must be installed first, since the PyTorch wheel declares it as a dependency with a specific version that doesn't exist on PyPI:

pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/triton-3.5.1%2Brocm7.2.0.gita272dfa8-cp312-cp312-linux_x86_64.whl
pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/torch-2.9.1%2Brocm7.2.0.lw.git7e1940d4-cp312-cp312-linux_x86_64.whl
pip install https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2/torchvision-0.24.0%2Brocm7.2.0.gitb919bd0c-cp312-cp312-linux_x86_64.whl

These are the ROCm 7.2 builds for Python 3.12. AMD also provides wheels for Python 3.10, 3.11, and 3.13.

Smoke Test

import torch
print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())
print("Device:", torch.cuda.get_device_name(0))
print("VRAM:", round(torch.cuda.get_device_properties(0).total_memory / 1e9, 1), "GB")

PyTorch: 2.9.1+rocm7.2.0.git7e1940d4
CUDA available: True
Device: AMD Radeon Graphics
VRAM: 103.1 GB

PyTorch detected the GPU through ROCm's HIP-to-CUDA translation layer. The 103.1 GB figure represents the total addressable memory on this unified-memory APU, which includes both the 96 GB GPU allocation and additional system memory accessible through the HSA runtime.

Note the use of torch.cuda despite this being an AMD GPU. ROCm's HIP runtime presents itself through PyTorch's CUDA interface, so all CUDA API calls in PyTorch (device selection, memory management, kernel launches) work transparently with AMD hardware.

Before and After Summary

Component	ROCm 7.0.2	ROCm 7.2.0
ROCm Version	7.0.2	7.2.0
amdgpu-dkms	6.14.14	6.16.13
ROCk Module	6.14.14	6.16.13
HSA Runtime Ext	1.11	1.15
amdgpu Repo	30.10.2	30.30
PyTorch	N/A	2.9.1+rocm7.2.0
Triton	N/A	3.5.1+rocm7.2.0
Kernel	6.14.0-37-generic	6.14.0-37-generic
Kernel Holds	In place	In place

Notes on gfx1151 Support

It's worth being explicit about the support situation. As of February 2026, gfx1151 (Strix Halo) is not listed on AMD's official ROCm support matrix. The supported RDNA 3 targets are gfx1100 (Navi 31, RX 7900 XTX) and gfx1101 (Navi 32). Strix Halo's gfx1151 is an RDNA 3.5 derivative that shares much of the ISA with gfx1100 but has architectural differences in the memory subsystem and compute unit layout.

In practice, ROCm 7.2 works on gfx1151. The kernel driver loads, rocminfo detects the GPU, and PyTorch can allocate tensors and dispatch compute kernels. The gfx11-generic ISA target in ROCm 7.2 is particularly helpful -- it provides a compatibility path for software that hasn't been explicitly compiled for gfx1151.

However, "works" and "fully supported" are different things. There are known quirks:

rocm-smi VRAM reporting: Always shows 0% on the APU since it only tracks discrete VRAM
No official PyTorch gfx1151 builds: The ROCm PyTorch wheels target gfx1100. They run on gfx1151 through ISA compatibility, but performance may not be optimal
Large model loading latency: Moving large models to the GPU device can be slow on the unified memory architecture, as the HSA runtime handles page migration differently than discrete GPU DMA transfers

If you're considering this hardware for production AI workloads, treat ROCm support as "functional but experimental." It works well enough for development, testing, and moderate inference workloads. For production training or latency-sensitive deployment, stick with hardware on AMD's official support list.

Rollback Plan

If the upgrade fails -- the DKMS module doesn't build, the GPU isn't detected after reboot, or something else goes wrong -- the rollback path is straightforward:

Uninstall ROCm 7.2:

sudo amdgpu-uninstall -y
sudo apt purge -y amdgpu-install

Reinstall ROCm 7.0.2:

wget https://repo.radeon.com/amdgpu-install/30.10.2/ubuntu/noble/amdgpu-install_30.10.2.0.30100200-2226257.24.04_all.deb
sudo apt install -y ./amdgpu-install_30.10.2.0.30100200-2226257.24.04_all.deb
sudo apt update
sudo amdgpu-install -y --usecase=graphics,rocm
sudo reboot

The entire rollback takes about 15 minutes. Keep the old amdgpu-install deb URL handy -- it's not linked from AMD's current download pages once a newer version is published.

Conclusion

Upgrading ROCm on hardware that isn't officially supported always carries some risk, but this upgrade from 7.0.2 to 7.2 on gfx1151 was uneventful. The procedure follows AMD's documented uninstall-reinstall approach with no deviations. The kernel hold strategy kept the kernel stable, the DKMS module built cleanly against 6.14.0-37-generic, and all post-reboot checks passed.

The improvements in ROCm 7.2 -- particularly the HSA runtime bump to 1.15 and the introduction of the gfx11-generic ISA target -- represent meaningful progress for Strix Halo users. The ecosystem is slowly catching up to the hardware. It's not there yet, but each release closes the gap.

For anyone running a Ryzen AI MAX+ 395 or similar Strix Halo hardware on Ubuntu 24.04, this upgrade is worth doing. The procedure is well-defined, the rollback path is clear, and the newer driver stack brings tangible benefits. Just remember to hold your kernel first.

Recommended Resources

Hardware

Bosgame M5 AI Mini PC (Ryzen AI MAX+ 395) - The system used in this post
GMKtec EVO X2 (Ryzen AI MAX+ 395) - Another Strix Halo mini PC option on Amazon

Books

Deep Learning with PyTorch by Stevens, Antiga, Huang, Viehmann - Comprehensive guide to building, training, and tuning neural networks with PyTorch
Programming PyTorch for Deep Learning by Ian Pointer - Practical guide to creating and deploying deep learning applications
Understanding Deep Learning by Simon Prince - Modern treatment of deep learning fundamentals

AMD AI Max+ 395 System Review: A Comprehensive Analysis

A.C. Jokela — Sun, 21 Sep 2025 20:25:28 GMT

Executive Summary

The AMD AI Max+ 395 system represents AMD's latest entry into the high-performance computing and AI acceleration market, featuring the company's cutting-edge Strix Halo architecture. This comprehensive review examines the system's performance characteristics, software compatibility, and overall viability for AI workloads and general computing tasks. While the hardware shows impressive potential with its 16-core CPU and integrated Radeon 8060S graphics, significant software ecosystem challenges, particularly with PyTorch/ROCm compatibility for the gfx1151 architecture, present substantial barriers to immediate adoption for AI development workflows.

Note: An Orange Pi 5 Max was photobombing this photograph

System Specifications and Architecture Overview

CPU Specifications

Processor: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
Architecture: x86_64 with Zen 5 cores
Cores/Threads: 16 cores / 32 threads
Base Clock: 599 MHz (minimum)
Boost Clock: 5,185 MHz (maximum)
Cache Configuration:
L1d Cache: 768 KiB (16 instances, 48 KiB per core)
L1i Cache: 512 KiB (16 instances, 32 KiB per core)
L2 Cache: 16 MiB (16 instances, 1 MiB per core)
L3 Cache: 64 MiB (2 instances, 32 MiB per CCX)
Instruction Set Extensions: Full AVX-512, AVX-VNNI, BF16 support

Memory Subsystem

Total System Memory: 32 GB DDR5
Memory Configuration: Unified memory architecture with shared GPU/CPU access
Memory Bandwidth: Achieved ~13.5 GB/s in multi-threaded tests

Graphics Processing Unit

GPU Architecture: Strix Halo (RDNA 3.5 based)
GPU Designation: gfx1151
Compute Units: 40 CUs (80 reported in ROCm, likely accounting for dual SIMD per CU)
Peak GPU Clock: 2,900 MHz
VRAM: 96 GB shared system memory (103 GB total addressable) - Note: This allocation was intentionally configured to maximize GPU memory for large language model inference
Memory Bandwidth: Shared with system memory
OpenCL Compute Units: 20 (as reported by clinfo)

Platform Details

Operating System: Ubuntu 24.04.3 LTS (Noble)
Kernel Version: 6.8.0-83-generic
Architecture: x86_64
Virtualization: AMD-V enabled

Performance Benchmarks

Figure 1: Comprehensive performance analysis and compatibility overview of the AMD AI Max+ 395 system

CPU Performance Analysis

Single-Threaded Performance

The sysbench CPU benchmark with prime number calculation revealed strong single-threaded performance:

Events per second: 6,368.92
Average latency: 0.16 ms
95th percentile latency: 0.16 ms

This performance places the AMD AI Max+ 395 in the upper tier of modern processors for single-threaded workloads, demonstrating the effectiveness of the Zen 5 architecture's IPC improvements and high boost clocks.

Multi-Threaded Performance

Multi-threaded testing across all 32 threads showed excellent scaling:

Events per second: 103,690.35
Scaling efficiency: 16.3x improvement over single-threaded (theoretical maximum 32x)
Thread fairness: Excellent distribution with minimal standard deviation

The scaling efficiency of approximately 51% indicates good multi-threading performance, though there's room for optimization in workloads that can fully utilize all available threads.

Memory Performance

Memory Bandwidth Testing

Memory performance testing using sysbench revealed:

Single-threaded bandwidth: 9.3 GB/s
Multi-threaded bandwidth: 13.5 GB/s (16 threads)
Latency characteristics: Sub-millisecond access times

The memory bandwidth results suggest the system is well-balanced for most workloads, though AI applications requiring extremely high memory bandwidth may find this a limiting factor compared to discrete GPU solutions with dedicated VRAM.

GPU Performance and Capabilities

Hardware Specifications

The integrated Radeon 8060S GPU presents impressive specifications on paper:

Architecture: RDNA 3.5 (Strix Halo)
Compute Units: 40 CUs with 2 SIMDs each
Memory Access: Full 96 GB of shared system memory
Clock Speed: Up to 2.9 GHz

OpenCL Capabilities

OpenCL enumeration reveals solid compute capabilities:

Device Type: GPU with full OpenCL 2.1 support
Max Compute Units: 20 (OpenCL reporting)
Max Work Group Size: 256
Image Support: Full 2D/3D image processing capabilities
Memory Allocation: Up to 87 GB maximum allocation

Network Performance Testing

Network infrastructure testing using iperf3 demonstrated excellent localhost performance:

Loopback Bandwidth: 122 Gbits/sec sustained
Latency: Minimal retransmissions (0 retries)
Consistency: Stable performance across 10-second test duration

This indicates robust internal networking capabilities suitable for distributed computing scenarios and high-bandwidth data transfer requirements.

PyTorch/ROCm Compatibility Analysis

Current State of ROCm Support

We installed ROCm 7.0 and related components: - ROCm Version: 7.0.0 - HIP Version: 7.0.51831 - PyTorch Version: 2.5.1+rocm6.2

gfx1151 Compatibility Issues

The most significant finding of this review centers on the gfx1151 architecture compatibility with current AI software stacks. Testing revealed critical limitations:

PyTorch Compatibility Problems

rocBLAS error: Cannot read TensileLibrary.dat: Illegal seek for GPU arch : gfx1151
List of available TensileLibrary Files:
- TensileLibrary_lazy_gfx1030.dat
- TensileLibrary_lazy_gfx906.dat
- TensileLibrary_lazy_gfx908.dat
- TensileLibrary_lazy_gfx942.dat
- TensileLibrary_lazy_gfx900.dat
- TensileLibrary_lazy_gfx90a.dat
- TensileLibrary_lazy_gfx1100.dat

This error indicates that PyTorch's ROCm backend lacks pre-compiled optimized kernels for the gfx1151 architecture. The absence of gfx1151 in the TensileLibrary files means:

No Optimized BLAS Operations: Matrix multiplication, convolutions, and other fundamental AI operations cannot leverage GPU acceleration
Training Workflows Broken: Most deep learning training pipelines will fail or fall back to CPU execution
Inference Limitations: Even basic neural network inference is compromised

Root Cause Analysis

The gfx1151 architecture represents a newer GPU design that hasn't been fully integrated into the ROCm software stack. While the hardware is detected and basic OpenCL operations function, the optimized compute libraries essential for AI workloads are missing.

Workaround Attempts

Testing various workarounds yielded limited success:

HSA_OVERRIDE_GFX_VERSION=11.0.0: Failed to resolve compatibility issues
CPU Fallback: PyTorch operates normally on CPU, but defeats the purpose of GPU acceleration
Basic GPU Operations: Simple tensor allocation succeeds, but compute operations fail

Software Ecosystem Gaps

Beyond PyTorch, the gfx1151 compatibility issues extend to:

TensorFlow: Likely similar rocBLAS dependency issues
JAX: ROCm backend compatibility uncertain
Scientific Computing: NumPy/SciPy GPU acceleration unavailable
Machine Learning Frameworks: Most frameworks dependent on rocBLAS will encounter issues

AMD GPU Software Support Ecosystem Analysis

Current State Assessment

AMD's GPU software ecosystem has made significant strides but remains fragmented compared to NVIDIA's CUDA platform:

Strengths

Open Source Foundation: ROCm's open-source nature enables community contributions
Standard API Support: OpenCL 2.1 and HIP provide industry-standard interfaces
Linux Integration: Strong kernel-level support through AMDGPU drivers
Professional Tools: rocm-smi and related utilities provide comprehensive monitoring

Weaknesses

Fragmented Architecture Support: New architectures like gfx1151 lag behind in software support
Limited Documentation: Less comprehensive than CUDA documentation
Smaller Developer Community: Fewer third-party tools and optimizations
Compatibility Matrix Complexity: Different software versions support different GPU architectures

Long-term Viability Concerns

The gfx1151 compatibility issues highlight broader ecosystem challenges:

Release Coordination Problems

Hardware releases outpace software ecosystem updates
Critical libraries (rocBLAS, Tensile) require architecture-specific optimization
Coordination between AMD hardware and software teams appears insufficient

Market Adoption Barriers

Developers hesitant to adopt platform with uncertain software support
Enterprise customers require guaranteed compatibility
Academic researchers need stable, well-documented platforms

Recommendations for AMD

Accelerated Software Development: Prioritize gfx1151 support in rocBLAS and related libraries
Pre-release Testing: Ensure software ecosystem readiness before hardware launches
Better Documentation: Comprehensive compatibility matrices and migration guides
Community Engagement: More responsive developer relations and support channels

Network Infrastructure and Connectivity

The system demonstrates excellent network performance characteristics suitable for modern computing workloads:

Internal Performance

Memory-to-Network Efficiency: 122 Gbps loopback performance indicates minimal bottlenecks
System Integration: Unified memory architecture benefits network-intensive applications
Scalability: Architecture suitable for distributed computing scenarios

External Connectivity Assessment

While specific external network testing wasn't performed, the system's infrastructure suggests:

Support for high-speed Ethernet (2.5GbE+)
Low-latency interconnects suitable for cluster computing
Adequate bandwidth for data center deployment scenarios

Power Efficiency and Thermal Characteristics

Limited thermal data was available during testing:

Idle Temperature: 29°C (GPU sensor)
Idle Power: 8.059W (GPU subsystem)
Thermal Management: Appears well-controlled under light loads

The unified architecture's power efficiency represents a significant advantage over discrete GPU solutions, particularly for mobile and edge computing applications.

Competitive Analysis

Comparison with Intel Arc

Intel's Arc GPUs face similar software ecosystem challenges, though Intel has made more aggressive investments in AI software stack development. The Arc series benefits from Intel's deeper software engineering resources but still lags behind NVIDIA in AI framework support.

Comparison with NVIDIA

NVIDIA maintains a substantial advantage in:

Software Maturity: CUDA ecosystem is mature and well-supported
AI Framework Integration: Native support across all major frameworks
Developer Tools: Comprehensive profiling and debugging tools
Documentation: Extensive, well-maintained documentation

AMD's advantages include:

Open Source Approach: More flexible licensing and community development
Unified Memory: Simplified programming model for certain applications
Cost: Potentially more cost-effective solutions

Market Positioning

The AMD AI Max+ 395 occupies a unique position as a high-performance integrated solution, but software limitations significantly impact its competitiveness in AI-focused markets.

Use Case Suitability Analysis

Recommended Use Cases

General Computing: Excellent performance for traditional computational workloads
Development Platforms: Strong for general software development (non-AI)
Edge Computing: Unified architecture benefits power-constrained deployments
Future AI Workloads: When software ecosystem matures

Not Recommended For

Current AI Development: gfx1151 compatibility issues are blocking
Production AI Inference: Unreliable software support
Machine Learning Research: Limited framework compatibility
Time-Critical Projects: Uncertain timeline for software fixes

Large Language Model Performance and Stability

Ollama LLM Inference Testing

Testing with Ollama reveals a mixed picture for LLM inference on the AMD AI Max+ 395 system. The platform successfully runs various models through CPU-based inference, though GPU acceleration faces significant challenges.

Performance Metrics

Testing with various model sizes revealed the following performance characteristics:

GPT-OSS 20B Model Performance:

Prompt evaluation rate: 61.29 tokens/second
Text generation rate: 8.99 tokens/second
Total inference time: ~13 seconds for 117 tokens
Memory utilization: ~54 GB VRAM usage

Llama 4 (67B) Model:

Successfully loads and runs
Generation coherent and accurate

The system demonstrates adequate performance for smaller models (20B parameters and below) when running through Ollama, though performance significantly lags behind NVIDIA GPUs with proper CUDA acceleration. The large unified memory configuration (96 GB VRAM, deliberately maximized for this testing) allows loading of substantial models that would typically require multiple GPUs or extensive system RAM on other platforms. This conscious decision to allocate maximum memory to the GPU was specifically made to evaluate the system's potential for large language model workloads.

Critical Stability Issues with Large Models

Driver Crashes with Advanced AI Workloads

Testing revealed severe stability issues when attempting to run larger models or when using AI-accelerated development tools:

Affected Scenarios:

Large Model Loading: GPT-OSS 120B model causes immediate amdgpu driver crashes
AI Development Tools: Continue.dev with certain LLMs triggers GPU reset
OpenAI Codex Integration: Consistent driver failures with models exceeding 70B parameters

GPU Reset Events

System logs reveal frequent GPU reset events during AI workload attempts:

[ 1030.960155] amdgpu 0000:c5:00.0: amdgpu: GPU reset begin!
[ 1033.972213] amdgpu 0000:c5:00.0: amdgpu: MODE2 reset
[ 1034.002615] amdgpu 0000:c5:00.0: amdgpu: GPU reset succeeded, trying to resume
[ 1034.003141] [drm] VRAM is lost due to GPU reset!
[ 1034.037824] amdgpu 0000:c5:00.0: amdgpu: GPU reset(1) succeeded!

These crashes result in:

Complete loss of VRAM contents
Application termination
Potential system instability requiring reboot
Interrupted workflows and data loss

Root Cause Analysis

The driver instability appears to stem from the same underlying issue as the PyTorch/ROCm incompatibility: immature driver support for the gfx1151 architecture. The drivers struggle with:

Memory Management: Large model allocations exceed driver's tested parameters
Compute Dispatch: Complex kernel launches trigger unhandled edge cases
Power State Transitions: Rapid load changes cause driver state machine failures
Synchronization Issues: Multi-threaded inference workloads expose race conditions

Implications for AI Development

The combination of LLM testing results and driver stability issues reinforces that the AMD AI Max+ 395 system, despite impressive hardware specifications, remains unsuitable for production AI workloads. The platform shows promise for future AI applications once driver maturity improves, but current limitations include:

Unreliable Large Model Support: Models over 70B parameters risk system crashes
Limited Tool Compatibility: Popular AI development tools cause instability
Workflow Interruptions: Frequent crashes disrupt development productivity
Data Loss Risk: VRAM resets can lose unsaved work or model states

Future Outlook and Development Roadmap

Short-term Expectations (3-6 months)

ROCm updates likely to address gfx1151 compatibility
PyTorch/TensorFlow support should improve
Community-driven workarounds may emerge

Medium-term Prospects (6-18 months)

Full AI framework support expected
Optimization improvements for Strix Halo architecture
Better documentation and developer resources

Long-term Considerations (18+ months)

AMD's commitment to open-source ecosystem should pay dividends
Potential for superior price/performance ratios
Growing developer community around ROCm platform

Conclusions and Recommendations

The AMD AI Max+ 395 system represents impressive hardware engineering with its unified memory architecture, strong CPU performance, and substantial GPU compute capabilities. However, critical software ecosystem gaps, particularly the gfx1151 compatibility issues with PyTorch and ROCm, severely limit its immediate utility for AI and machine learning workloads.

Key Findings Summary

Hardware Strengths:

Excellent CPU performance with 16 Zen 5 cores
Innovative unified memory architecture with 96 GB addressable
Strong integrated GPU with 40 compute units
Efficient power management and thermal characteristics

Software Limitations:

Critical gfx1151 architecture support gaps in ROCm ecosystem
PyTorch integration completely broken for GPU acceleration
Limited AI framework compatibility across the board
Insufficient documentation for troubleshooting

Market Position:

Competitive hardware specifications
Unique integrated architecture advantages
Significant software ecosystem disadvantages versus NVIDIA
Uncertain timeline for compatibility improvements

Purchasing Recommendations

Buy If: - Primary use case is general computing or traditional HPC workloads - Willing to wait 6-12 months for AI software ecosystem maturity - Value open-source software development approach - Need power-efficient integrated solution

Avoid If:

Immediate AI/ML development requirements
Production AI inference deployments planned
Time-critical project timelines
Require guaranteed software support

Final Verdict

The AMD AI Max+ 395 system shows tremendous promise as a unified computing platform, but premature software ecosystem development makes it unsuitable for current AI workloads. Organizations should monitor ROCm development progress closely, as this hardware could become highly competitive once software support matures. For general computing applications, the system offers excellent performance and value, representing AMD's continued progress in processor design and integration.

The AMD AI Max+ 395 represents a glimpse into the future of integrated computing platforms, but early adopters should be prepared for software ecosystem growing pains. As AMD continues investing in ROCm development and the open-source community contributes solutions, this platform has the potential to become a compelling alternative to NVIDIA's ecosystem dominance.