Mesa 3D Graphics Lib

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.


--- ChangeLog:

1.0 (21.08.2026):

   - Initial first public release.

1.1 (01.09.2026):

   CORE
   ====
   
   - Fixed big-endian serialization of 64-bit uniforms  and bindless texture
     /image handles into GPU constant buffers.

   - Fixed a big-endian bug that caused scissored glClear operations on FBOs
     to write (0,0,0,0) instead of the requested clear color.
     Thanks to AfxGroup for the report!

   - Added Mesa's pb_cache-based GPU buffer reuse, reducing allocation over-
     head and improving FPS.

   - Handled  cases where  GART buffer allocations fall back to VRAM, fixing
     intermittent slowdowns and rendering flicker.
     Thanks to Martin0873 and dirk67 for reports! 

   - Removed the hardcoded  requirement for 32-bit screen modes. Three paths
     are now supported:
          - Native RGB565 on 16-bit screens.
          - Native ARGB8888 on 32-bit screens.
          - A fallback path for apps requesting ARGB8888 on a 16-bit screen,
            with internal conversion to RGB565 (slower).
     Thanks to Peb for the report!

   - Worked around a Radeon HD bug  that failed to clear  all graphics state
     when switching between 3D rendering and screen updates. Mesa apps using
     programmable point sprites no longer hang the GPU.

   - Work around a Radeon HD 5.x bug  that groups  Oland (chip ID 0x42) with
     Hainan (0x43), causing Hainan's two-tile-pipe table to be programmed on
     Oland GPUs, which normally use 4 tile pipes. At Mesa  startup, affected
     Oland  configs are  detected  and reprogrammed with  the correct tiling
     table for  the  lifetime of the  session. This  fixes visual corruption
     affecting 1D tiling, antialiasing, and related rendering paths.

   - Fixed black output on RadeonHD 3.x in legacy applications using glBegin
     glEnd. NOTE: RadeonHD 3.x is still not recommended due to its very poor
     performance.

   - The ATOM parser now tolerates option-ROM checksum mismatches instead of
     failing, as some cards have a VBIOS with a stale container checksum.
     Thanks to 328gts for report and tests!
 
   - GL_RENDERER now reports the  Radeon driver's  Resource Manager (RM) API
     version instead of the irrelevant Linux DRM version 0.0.
 
   - Added automatic build dates to mesa.library version information.
   
   - Improved runtime error  reporting by  replacing  cryptic  internal enum
     values with meaningful descriptions.
  
   TOOLS AND BENCHMARKS
   ====================

   - c:radeon_gpu_info now  also reports the mesa.library  version and date.

   - Improved glMark2:
     - Added mesa.library add driver version information.
     - Removed misleading EGL state errors.
     - Fixed AOS4 bitmap detection  for correct operation on both 16-bit and
       32-bit screens.

   - Added FixedGL, a benchmark for testing the legacy OpenGL fixed-function
     pipeline: glBegin/glEnd, immediate mode, client arrays,  display lists,
     fixed matrices, fog, etc.

   - Improved ShaderToy benchs:
     - Added window resizing.
     - Added double-click switching between windowed and fullscreen.
     - Added proper support for both 16-bit and 32-bit screen modes.
     - Added average FPS information on exit.
     - Added four new high-quality shaders.