.. meta:: :description: System optimization of AMD RDNA3.5 Ryzen APUs (gfx1150/gfx1151/gfx1152) systems. Learn about VRAM, GTT, TTM tuning, shared memory configuration, and required Linux kernel support. :keywords: AMD RDNA3.5, Ryzen APU, gfx1150, gfx1151, gfx1152, ROCm, VRAM, GTT, GART, TTM, GPUVM, system optimization .. _strix-halo-optimization: ========================================== AMD RDNA3.5 system optimization ========================================== This topic describes how to optimize systems powered by AMD Ryzen APUs with RDNA3.5 architecture. These APUs combine high-performance CPU cores with integrated RDNA3.5 graphics, and support LPDDR5X-8000 or DDR5 memory, making them particularly well-suited for: * LLM development and inference systems * High-performance workstations * Virtualization hosts running multiple VMs * GPU compute and parallel processing * Gaming systems * Home servers and AI development platforms .. _memory-settings: Memory settings =============== AMD Ryzen APUs with RDNA3.5 architecture (gfx1150, gfx1151, and gfx1152 LLVM targets) handle memory access through GPU Virtual Memory (GPUVM), which provides per-process GPU virtual address spaces (VMIDs) rather than a separate, discrete VRAM pool. As a result, memory on RDNA3.5 APUs is mapped rather than physically partitioned. The terms Graphics Address Remapping Table (GART) and Graphics Translation Table (GTT) describe limits on how much system memory can be mapped into GPU address spaces and who can use it, rather than distinct types of physical memory. * **GART** Defines the amount of platform address space (system RAM or Memory-Mapped I/O) that can be mapped into the GPU virtual address space used by the kernel driver. On systems with physically shared CPU and GPU memory, such as RDNA3.5-based systems, this mapped system memory effectively serves as VRAM for the GPU. GART is typically kept relatively small to limit GPU page-table size and is primarily used for driver-internal operations. * **GTT** Defines the amount of system RAM that can be mapped into GPU virtual address spaces for user processes. This is the memory pool used by applications such as PyTorch and other AI/compute workloads. GTT allocations are dynamic and not permanently reserved, allowing the operating system to reclaim memory when the GPU isn't actively using it. By default, the GTT limit is set to approximately 50 percent of total system RAM. .. note:: On systems with physically shared CPU and GPU memory, such as RDNA3.5-based systems, several terms are often used interchangeably in firmware menus, documentation, and community discussions: * VRAM * Carve-out * GART * Dedicated GPU memory * Firmware-reserved GPU memory In this topic, VRAM will be used going forward. You can adjust the amount of memory available to the GPU by: * Increasing the VRAM in BIOS, or * Reducing the configured GTT size to be smaller than the reserved amount. If the GTT size is larger than the VRAM, the AMD GPU driver performs VRAM allocations using GTT (GTT-backed allocations), as described in the `torvalds/linux@759e764 `_ GitHub commit. Because memory is physically shared, there's no performance distinction like that of discrete GPUs, where dedicated VRAM is significantly faster than system memory. Firmware may optionally reserve some memory exclusively for GPU use, but this provides little benefit for most workloads while permanently reducing available system memory. For this reason, AI frameworks work more efficiently with GTT-backed allocations. GTT allows large, flexible mappings without permanently reserving memory, resulting in better overall system utilization on unified memory systems. Configuring shared memory limits on Linux ----------------------------------------- The maximum amount of shared GPU-accessible memory can be increased by changing the kernel **Translation Table Manager (TTM)** page limit. This setting controls how many system memory pages can be mapped for GPU use and is exposed at: :: /sys/module/ttm/parameters/pages_limit The value is expressed in pages, and not bytes or gigabytes (GB). .. note:: It's recommended to keep the dedicated VRAM reservation in BIOS small (for example, 0.5 GB) and increase the shared (TTM/GTT) limit instead. A helper utility is available to simplify configuration. 1. Install ``pipx``: :: sudo apt install pipx pipx ensurepath 2. Install the AMD debug tools: :: pipx install amd-debug-tools 3. Query the current shared memory configuration: :: amd-ttm 4. Set the usable shared memory (in GB): :: amd-ttm --set 5. Reboot for changes to take effect. .. note:: The amd-ttm command converts the pages to GB to help the users. Example with output ^^^^^^^^^^^^^^^^^^^ Check the current settings: :: amd-ttm 💻 Current TTM pages limit: 16469033 pages (62.82 GB) 💻 Total system memory: 125.65 GB Change the usable shared memory: :: ❯ amd-ttm --set 100 🐧 Successfully set TTM pages limit to 26214400 pages (100.00 GB) 🐧 Configuration written to /etc/modprobe.d/ttm.conf ○ NOTE: You need to reboot for changes to take effect. Would you like to reboot the system now? (y/n): y Revert to kernel defaults: :: ❯ amd-ttm --clear 🐧 Configuration /etc/modprobe.d/ttm.conf removed Would you like to reboot the system now? (y/n): y .. _operating-system-support: Operating system support ======================== The ROCm operating system requirements are available in :ref:`Operating system support `. AMD Ryzen AI Max series APUs (gfx1151) have additional kernel version requirements, as described in the following section. Required Linux kernel version ----------------------------- Support for AMD Ryzen AI Max series APUs requires specific Linux kernel fixes that update internal limits in the AMD KFD driver to ensure correct queue creation and memory availability checks. Without these updates, GPU compute workloads might fail to initialize or exhibit unpredictable behavior. The following commits are required for AMD Ryzen AI Max series support: - `gregkh/linux@7f26af7 `_ - `gregkh/linux@7445db6 `_ These patches are available in the following minimum kernel versions: - Ubuntu 24.04 Hardware Enablement (HWE): ``6.17.0-19.19~24.04.2`` or later - Ubuntu 24.04 Original Equipment Manufacturer (OEM): ``6.14.0-1018`` or later - All other distributions: Linux kernel ``6.18.4`` or later The table below reflects compatibility for AMD-released pre-built ROCm binaries only. Distributions that ship native ROCm packaging might provide different support levels. .. list-table:: :header-rows: 0 :widths: 10 90 * - ❌ - Unsupported combination * - ⚠️ - Unstable/experimental combination * - ✅ - Stable and supported combination .. list-table:: :header-rows: 1 :widths: 20 50 15 15 * - ROCm Release - | Ubuntu 24.04 HWE (>= 6.17.0-19.19~24.04.2), | Ubuntu 24.04 OEM (>= 6.14.0-1018) or | Ubuntu 26.04 Generic - Other distributions >= 6.18.4 - Other distributions < 6.18.4 * - 7.11.0 or 7.12.0 - ✅ - ✅ - ⚠️ * - 7.9.0 or 7.10.0 - ❌ - ❌ - ⚠️ * - 7.2.1, 7.2.2 or 7.2.3 - ✅ - ✅ - ⚠️ * - 7.2.0 - ✅ - ✅ - ❌ * - 7.1.x - ❌ - ❌ - ⚠️ * - 6.4.x - ❌ - ❌ - ⚠️ .. note:: Ubuntu 24.04 HWE kernels earlier than ``6.17.0-19.19~24.04.2`` and Ubuntu 24.04 OEM kernels earlier than ``6.14.0-1018`` are not supported for RDNA3.5 APUs. The following distributions include the required fixes in their native packaging, independent of AMD pre-built binaries: - Fedora 43 - Ubuntu 26.04 - Arch Linux 2026.02.01