Reply to thread

Message: [QUOTE="Bombastus, post: 91512, member: 2178"] AMD lists Ubuntu 24.04.4 with the 6.17 kernel for ROCm 10 on Ryzen AI Max PRO 400 processors. A machine can show the right Ubuntu version and still boot the wrong kernel for this configuration. The [B][URL='https://goldmidi.com/community/threads/minisforum-has-introduced-the-ms-s1-max-p495-workstation.76847/']MS-S1 MAX-P495’s integrated Radeon graphics[/URL][/B] fall under Ryzen APU support, not the separate desktop Radeon category. Those categories have different driver requirements. Copying a desktop GPU command can mean installing a driver the Ryzen setup doesn't call for. [HEADING=2]Ubuntu’s version number is not enough[/HEADING] For a fresh installation, Ubuntu 24.04.4 with its 6.17 hardware-enablement kernel provides one documented starting point. ROCm 10 also lists Ubuntu 26.04 with kernel 7.0, so upgrading the operating system is an alternative, not a requirement. Check the running kernel with uname -r before touching the compute packages. A system still booting kernel 6.8 does not match the listed Ryzen configuration. An installed kernel isn't necessarily the one you booted. AMD specifies the driver shipped with those supported Ubuntu kernels for Ryzen APUs. A separate AMDGPU DKMS installation from an older walkthrough isn't part of that configuration. Check the processor name too. AMD added the Ryzen AI Max+ PRO 495 to production ROCm support in release 7.14.0, identifying its graphics target as gfx1151. Older instructions may describe a different chip, even when the workstation name looks familiar. AMD’s older Ryzen compatibility page still describes ROCm 7.2.1 and lists the 395. The ROCm 10 matrix includes the newer processor family, so the two pages describe different software releases. The shared gfx1151 label identifies a graphics architecture, not every release that supports a particular processor. Keep the processor model attached to the release you're checking. Missing hardware in a 7.2.1 table says nothing definitive about support in 10. [HEADING=2]Old paths can survive a new installation[/HEADING] With system packages, ROCm 10 installs its core files under /opt/rocm/core-10.0 rather than the older versioned directory layout. Its package names also use the amdrocm prefix, which separates them from legacy packages. For Ubuntu, register AMD’s stable repository for your chosen Ubuntu release before installing its packages. The architecture-specific base package is amdrocm10.0-gfx1151. It supplies the runtime and libraries for running applications, rather than every optional development tool. A package-managed installation also supplies compatibility links for familiar locations such as /opt/rocm/bin and /opt/rocm/lib. An old script using those locations may therefore work without being rewritten. A script pointing directly at /opt/rocm-7.2/bin won't start using version 10 merely because you've installed it. Its path still selects the old directory. A missing-file error here can mean a stale path, not a broken new installation. Unpacking a tarball doesn't create those compatibility links or install missing dependencies. You must set PATH, LD_LIBRARY_PATH, and ROCM_PATH for the extracted directory and install any missing dependencies yourself. Suppose your shell still searches an older ROCm directory first. Unpacking new files elsewhere doesn't change that search order. A plain command and its full path can therefore start different copies of the same utility. [HEADING=2]PyTorch needs more than an installed runtime[/HEADING] Installing ROCm libraries does not, by itself, install PyTorch. The framework has its own distribution, and its supported build needs to match the ROCm environment you intend to use. For Python-only work, you can install ROCm in a virtual environment rather than across the system. The libraries extra supplies host-side math libraries. The device-gfx1151 extra adds precompiled GPU kernels for this graphics target. Development tools serve a different job, providing compilers and headers for building software. Adding them doesn't replace the architecture-specific kernels needed to run GPU work. Use the same account that will launch the application when checking GPU access. It normally needs membership in the render and video groups. Administrator-only testing can hide a permissions problem your regular account will encounter. After changing those memberships, reboot before retesting so the changes take effect. Running rocminfo as your ordinary user should then show a GPU entry for gfx1151, not merely CPU information. After importing PyTorch, torch.version.hip identifies a HIP-enabled build, while torch.cuda.is_available() checks GPU availability. The CUDA name is intentional because PyTorch reuses that interface for AMD hardware. Replacing cuda with rocm isn't a fix because PyTorch does not accept that device name. Follow detection with [B]a small calculation on the integrated GPU[/B], rather than downloading a large model immediately. In the same Python environment, torch.ones(4, device="cuda").sum().item() should return 4.0. This requests GPU allocation and a reduction, so it tests more than whether a device name appears. An application started in a different Python environment may still load another PyTorch build. After importing sys, sys.executable reveals the interpreter actually running, which may not be the one you used for the successful test. [/QUOTE]

Name