ROCmLibs for gfx1103: prebuilt ROCm libraries for the AMD 780M on Windows

A repository of binary archives, not a source tree

The repository description calls it ROCm Library Files for gfx1103, updated with other architectures based on AMD GPUs for use in Windows. The top level entries make the shape of the project unmistakable.

There is no source code to compile and no build system. What is there are archives: several files named for the architecture, the APU and the HIP SDK version they target, one named rocBLAS-Custom-Logic-Files.7z, and one long file whose name enumerates the GPU families a second archive covers. There are also two patch files, Tensile-fix-fallback-arch-build.patch and Tensile-fix-fallback-arch-build-hip-6.1.2.patch, a tensile_tuning.pdf document, and the README and LICENSE.

So the deliverable is a set of DLLs and their accompanying logic files, zipped. The primary language field is listed as unknown, which is consistent with a repository whose contents are binaries.

The origin is explained in the readme. The repository was initially created to share optimized ROCm libraries specifically for the AMD 780M APU's gfx1103 architecture, due to limited official support, and it has since grown to include more AMD GPU architectures using the same proven build methods. The stated intent is to boost performance in popular applications such as AI models, with Llama and Stable Diffusion named, within the ZLUDA CUDA wrapper and other ROCm based environments.

All of the code is stated to be based on the official ROCm Linux version as explained in the project wiki, with additional tweaks and optimizations to address the gap in official support. The readme adds a note that the licence may also comply with this if there are other needs, which is a slightly loose formulation, and the licence field on the repository says GPL-3.0.

The install is a file swap inside your HIP SDK

The procedure is four steps, and step three is the part where you can break your installation.

First, the prerequisite is the HIP SDK installed for Windows. Second, you download the archive matching your architecture, for example rocm gfx1103 AMD780M phoenix V3 for hip sdk 5.7.7z, which was originally ROCmLibsgfx1103.zip.

Third is the replacement. You back up the original library and rocblas.dll in your %HIP_PATH%\bin\ and the %HIP_PATH%\bin\rocblas directory, by renaming the existing rocblas folder, for instance to oldlibrary, and rocblas.dll to oldrocblas.dll. The readme notes the backup is only for development purposes, otherwise you can simply delete them.

Then you unzip the archive. The extracted library folder goes into your %HIP_PATH%\bin\rocblas directory, and rocblas.dll goes into %HIP_PATH%\bin\, with the example given as C:\Program Files\AMD\ROCm\5.7\bin. You replace the original file.

Fourth is an optional reboot, since the documentation says restarting is for the changes to take effect and is not a must do.

The reason this matters is that you are overwriting the vendor's own rocblas.dll with one built for a different architecture. That is what makes the difference between the official ROCm build, which has no code path for gfx1103, and one that does. It also means a mismatch between the archive and your SDK version produces a library that loads but computes the wrong answers, which is a worse failure than a load error.

The readme is explicit about one rule: always choose the file version that matches your installed HIP SDK.

One archive per HIP SDK version, and the list of what exists

The compatibility table is a list of archives mapped to SDK versions, and it is the reference you need before downloading anything.

For the 780M on Windows, the recommended files are rocm gfx1103 AMD 780M phoenix V2.0 for hip sdk 5.7.7z, compatible with HIP SDK 5.7.1; the V3 archive, also for HIP SDK 5.7.1; V4.0 for HIP SDK 6.1.2; V5.0 for HIP SDK 6.2.4; a plain rocm gfx1103 for hip sdk 6.4.2.7z for HIP SDK 6.4.2; and rocm gfx1103 for hip sdk 7.1.1.7z for HIP SDK 7.1.1.

The release tags in the repository follow the same pattern, with links for Hip SDK 5.7, 6.1.2, 6.2.4, 6.4.2 and 7.1.1. The listed releases are v0.7.1.1 from 2026-05-17, v0.6.4.2 from 2025-08-30 and v0.6.2.4 from 2024-12-25.

The architecture coverage is broader than the original 780M focus. The readme lists custom built libraries for gfx803, gfx902, gfx90c, gfx90c:xnack-, gfx906, gfx1010, gfx1010:xnack-, gfx1011, gfx1012, gfx1012:xnack-, gfx1031, gfx1032, gfx1034, gfx1035, gfx1036, gfx1103 and gfx1150, with gfx1150 marked experimental only. The builds for those other architectures moved to the releases page.

The xnack- variants are worth noting for anyone with an Instinct card, since the xnack memory model changes the compiled kernels and the two variants are not interchangeable.

There is a separate archive, rocBLAS-Custom-Logic-Files.7z, which contains logic files optimised for various AMD GPUs: Rx 580, the Vega series, Navi 10 through Navi 26, Rembrandt and Phoenix. The wiki has the detailed guide for building rocBLAS and using those custom logic files.

The Linux answer is an environment variable, not a file swap

The readme takes a different position on Linux, and it is a strong one. ROCm is available for Linux on the releases page, but the documentation recommends against using it directly, on the grounds that there are simpler and more effective methods for achieving compatibility.

The simplest method is the HSA_OVERRIDE_GFX_VERSION environment variable. Setting export HSA_OVERRIDE_GFX_VERSION=11.0.0 can override the system's default and provide support for gfx1103 and similar GPUs.

That is a completely different mechanism from the Windows approach, and the difference is instructive. On Linux the kernel driver and the runtime both pick up the override at load time, so you are telling the stack to believe it is talking to a different architecture. On Windows the HIP SDK ships with a fixed rocblas.dll, so the only way to change what the BLAS implementation does is to replace the file.

That is also why the Windows route is more fragile. The override is a runtime hint that the driver understands, and if the hardware does not behave exactly like the emulated architecture the failure is subtle. The file replacement is unconditional, and if the SDK version does not match the library build, the mismatch surfaces as wrong results rather than an error.

The tooling targets are listed too: ollama with a dedicated repository, llama.cpp, SD.Next, Stable Diffusion DirectML, stable-diffusion-webui-forge-on-amd, stable-diffusion-webui-amdgpu-forge, a wiki page on training Flux LoRA models with FluxGym and ZLUDA on Windows, and a wiki page on unlocking LM Studio on any AMD GPU with ROCm.

The readme also asks that unrelated issues about ollama-for-amd not be filed here, and to submit them to the correct repository.

Where these libraries stop working

The limits are structural, and they come from the approach rather than from the quality of the build.

The first is version coupling. Every archive is tied to one HIP SDK version, and the readme says twice to always choose the file version that matches your installed HIP SDK. When AMD ships a new HIP SDK, there is a window in which your installed stack has no matching library, and the answer is to wait for a new archive or to downgrade the SDK. The project cannot fix that, because it is not the vendor.

The second is that this is Windows only. The files are DLLs dropped into an AMD directory, and the Linux route is a different mechanism entirely. A cross platform team cannot use one artefact for both.

The third is that there is no supported upgrade path. You are overwriting a vendor file in place, with a backup whose only role is to let you undo the change. There is no package manager integration, no signature, no way to verify that the archive you downloaded corresponds to the build the project published. The download integrity rests on the release page and your own judgement.

The fourth is the coverage of the underlying hardware. The point of gfx1103 is that AMD does not officially support the 780M in ROCm, so these libraries are a community approximation of an official build. The readme describes performance gains often 2 to 3 times faster than DirectML in applications like the ones listed, which is a claim from the project rather than an independently verified figure, and it is a comparison against DirectML rather than against a supported ROCm path that does not exist for this chip.

For someone whose alternative is a CPU or a DirectML path, that is still a large improvement. For someone comparing against a supported discrete AMD GPU on Linux with ROCm, the picture is different.

Editorial conclusion

This repository suits a Windows user with an AMD 780M laptop or a supported older AMD GPU who wants to run ROCm based tooling that AMD does not support officially, and who is willing to replace files inside their HIP SDK installation. It does not suit anyone who wants to build from source, since the repository contains binary archives and patches rather than a buildable tree, and it does not suit a Linux user, where the documentation recommends a different approach entirely. Before installing, confirm your HIP SDK version and pick the matching archive, because mixing a library build from one SDK with another SDK install is the failure mode the documentation repeatedly warns about.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. likelovewant/ROCmLibs-for-gfx1103-AMD780M-APU on GitHub
4. README
5. Releases