
MESA for AmigaOS4
--- Introduction:
Yes, you read that correctly: full-blown MESA for AmigaOS4! And no, this is
not a software-based, half-working version. It is fully hardware-accelerated
Mesa, supporting OpenGL up to version 4.6 and OpenGL ES up to version 3.2.
And yes, Gallium, RadeonSI, NIR, ACO, and everything else are included.
And it is FREE! No payment for the time spent on this port is requested,
there is no charge for updates, there is no need to register your interest,
and there are no pre-orders or pointless PDFs. FREE as it should be! Check
this out and pump up the volume!
https://www.youtube.com/watch?v=NdXbn2V0ZV4
This port is based on Mesa 26.1.5 (2026-07-15). It completely bypasses
ogles2.library and warp3dnova.library and works directly with the Radeon
drivers. To make this possible, I had to disassemble the RadeonRX and
RadeonHD drivers, discover how to use them and which APIs they provide, and
write Mesa's winsys bridge to connect it to A-EON's drivers.
This also means that you still need A-EON's Radeon drivers until free
replacements become available.
--- What has been done? Is it bug-free? Is it stable?
The current version has been tested on the X1000, X5000, Sam460, and
Pegasos2 through a PCI-to-PCIe bridge. Tested RadeonHD cards cover Oland,
Cape Verde, Pitcairn, and Tahiti, including the R7 240, R7 250, and R9 280.
Tested RadeonRX cards cover Polaris 10, 11, and 12, including the RX 550, RX
560, RX 570, and RX 580. Beta testing was performed by four testers, so the
first release should be in good shape.
The complete list of changes is long. These are the most important parts:
-- a native "winsys" bridge for direct use of A-EON's RadeonRX and
RadeonHD drivers
-- support for Resource Manager API: v3 in RadeonRX 2.12 and RadeonHD
5.20, and API v1 in RadeonHD 3.7
-- a native mesa.library shared by all GL and OpenGL ES clients, with
support for multiple simultaneous clients
-- a private resident heap for Mesa and C++ allocations
-- ACO and NIR shader compilation without LLVM
-- correct little-endian ACO shader-code and relocation uploads
-- extensive big-endian fixes for vertex descriptors, formats, inputs,
index handling, and other GPU data paths
-- adaptation of RadeonSI's address32 GPU-VA optimisation
-- avoidance of unnecessary full 64-bit GPU-address handling
-- GART-preferred memory with a validated non-GART fallback
-- a runtime-selected cache policy for better performance
-- a native Exec/DOS threading implementation for GCC gthreads and
Mesa's pthread and C11 threading
-- a fast GLAPI current-context path that bypasses slow GCC emuTLS on
hot OpenGL entrypoints
-- native PPC32 assembly GLAPI dispatch entrypoints
-- a worker-free CPU queue mode for our single core systems
-- RadeonHD-specific compatibility and state-restoration fixes
-- RadeonHD Oland fixes for texture tiling and GPU hangs
-- and much more
Of course, work of this scale is unlikely to be entirely bug-free, and some
issues will certainly need to be addressed in future versions. However, the
port in its current form is mature enough to be used by both users and
developers. I hope you will help me shake out the remaining bugs. With your
reports, we can continue making it better. I am sure there is still plenty
to improve.
--- Speed:
The first question you may ask is: what about speed? The answer is that it
is faster. When emulating the fixed-function pipeline (which is what GL4ES
provides on top of ogles2.library and warp3dnova.library), Mesa is usually
faster, sometimes about the same, and much faster in some areas. As an
example, with identical settings, Quake 3 reaches 125 FPS with the GL4ES
build and 155 FPS with the Mesa build. That is not a huge difference, at
least for now, but it is still an improvement.
But fixed-function pipeline belongs to the old OpenGL 2.x era. When it comes
to OpenGL 3 / 4 and shaders use, Mesa brings much more. Shader compatibility
is far better than with the old Warp3D Nova shader compiler. The tested
shader paths are no longer limited by its SGPR and VGPR restrictions,and the
related ring hangs have been eliminated. Some shaders run two,three, or even
four times faster.
This Mesa port uses all the things available to it,including cache coherency,
GART, fences, and asynchronous GPU submission and presentation. For the best
performance, use the latest public drivers:
RadeonRX => 2.12
RadeonHD => 5.20 (RadeonHD 3.7 also works, but is _NOT_ recommended)
Yes, some people still prefer RadeonHD 3.7 because of working warm reboot.
However, version 3.7 has no usable GART path and can be much slower than
RadeonHD 5.20. On the X1000, it is three to four times slower in some areas.
Mesa still can work with RadeonHD 3.7, but it is much slower than with 5.20.
You have been warned!
Also, none of A-EON's public RadeonHD or RadeonRX drivers provides a working
GART path on the Sam460. Mesa port therefore uses a non-GART fallback on the
systems which don't have working GART,which is not as bad as it might sound.
For Mesa on AmigaOS4, cards with more compute units and texture units will
generally perform better. Of all the RadeonHD and RadeonRX cards tested so
far, the fastest was:
Radeon RX 580 (Polaris 10), with 36 active CUs and 144 texture units
(four texture units per CU)
The fastest tested RadeonHD card was:
Radeon R9 280X Dual-X (Tahiti), with 28 active CUs and 112 texture units
A RadeonHD card therefore also works well when used with the RadeonHD 5.20
driver. RadeonRX is still somewhat faster, but both ranges are competitive.
Another video demonstrates the speed of Shadertoy shaders on a Radeon RX 570
with 32 active CUs and 128 texture units. Most of these shaders did not
compile with the Warp3D Nova shader compiler. Those that did were often many
times slower than with the current Mesa port:
https://www.youtube.com/watch?v=8cczEMpNA2k
--- What is missing, and what is planned for future versions?
-- a persistent on-disk shader cache
-- further bug fixes, endian fixes, and optimisations
--- Outro:
That is it. The Mesa archive includes an SDK, so you can use it right away.
It also includes several tests, such as standalone Shadertoy examples and
the glmark2 benchmark suite. In C: you will also find a program that queries
and displays information about your RadeonHD or RadeonRX card.
Grab it from OS4Depot while it is hot, and never say never!
(c) kas1e 2026.08.20

