Small but important frontend update: the standard Khronos path now supports real EGL_WINDOW_BIT surfaces, not just pbuffers.

A normal app can now pass a public CAMetalLayer, NSView, or NSWindow into eglCreateWindowSurface(). Mesa still owns EGL/OpenGL and the state tracker; AO46 only handles the public Cocoa/Metal drawable lifecycle underneath. No CGL, no NSOpenGL, no legacy AO46 runtime sneaking back in through a side door.

The Metal backend now acquires the Cocoa layer, maps the live Gallium color resource to its Metal texture, copies into the current CAMetalDrawable, presents it, and keeps the source alive until GPU completion. It also handles backing-size changes, drawable loss, sRGB RGBA8/BGRA8, and swap intervals 0/1.

The ao46mtl EGL driver now advertises both:

EGL_PBUFFER_BIT | EGL_WINDOW_BIT

and handles front/depth resource allocation, refresh on Cocoa layer changes, and presentation through eglSwapBuffers().

I also moved the shared Metal/Gallium screen, NIR, RGB32 and poly support into AO46MTLGallium, so the modern frontend no longer quietly depends on the old CGL-side runtime bundle.

This thus completes the seperate modern Standard Khronos EGL + OGL ABI frontend in parallel to the legacy NSOpenGL + CGL + OpenGL Framework path , which is kept in parallel for Apple only compatibility [ie Apps that have a Cocoa + AppKit frontend and requires the .framework ]

After digging through the architecture again, I think we finally removed one of the biggest reasons someone would hesitate before even trying AO46: the whole “disable SIP + authenticated root first” problem does not actually have to be a fundamental requirement of the driver.

That requirement mostly came from the original compatibility goal.

AO46 was designed to replace Apple’s existing OpenGL stack closely enough that old macOS applications could continue using OpenGL.framework, CGL and NSOpenGL without being rewritten. If you want to transparently replace something living inside Apple’s protected system volume, then naturally macOS security gets involved. SIP/SSV/AuthRoot becomes part of the installation story, and telling someone to reboot into Recovery before testing an OpenGL driver is... not exactly the friendliest first impression. 💀

The mistake was treating that installation model as if it had to apply to every AO46 use case.

It doesn’t.

The new direction is to keep the Apple ABI as a compatibility frontend, while adding a completely separate Khronos-native frontend for new applications.

New AO46 applications would be able to target normal desktop OpenGL together with EGL instead of depending on NSOpenGLContext, CGLContextObj, Apple pixel formats, etc.

So the legacy path still exists for what it was designed for: old macOS software.

But new software would just use the Khronos interfaces and load AO46 from normal userspace. No modification of /System/Library, no replacing Apple’s OpenGL framework, and therefore no inherent reason to disable SIP or authenticated root just to use that path.

This also clears up the Vulkan side of the project.

I originally considered making AVK143 mirror AO46 too literally, with things like an NSVulkan_KHR layer and a CVK ABI. After looking at the problem properly, that really doesn’t make much sense.

Vulkan already solved this problem.

It already has the standard Vulkan loader, ICD discovery, driver dispatch, WSI, VkSurfaceKHR, swapchains, extension handling, validation layers and a defined loader ↔ driver contract.

So AVK143 should simply be a normal Vulkan driver.

A Vulkan application talks to the Khronos loader, the loader discovers AVK143, and AVK143 handles the macOS/Apple GPU side underneath it.

There is no old Apple Vulkan ABI that needs preserving, so inventing one would just give developers another proprietary API to target for absolutely no benefit.

This also means a lot of infrastructure simply does not need to be rewritten.

The Vulkan loader already exists.

Vulkan headers already exist.

Mesa already has common Vulkan runtime infrastructure.

Mesa already has EGL infrastructure.

Khronos already defines the API and most of the WSI-facing contracts.

The project should spend its effort on the parts that are actually specific to this platform: resource handling, synchronization, compiler/backend work, command execution, presentation and the macOS/AGX boundary.

So the project is starting to separate into three pretty clear interfaces:

Existing macOS OpenGL applications: keep using OpenGL.framework / CGL / NSOpenGL through AO46’s compatibility mode.

New OpenGL applications: use standard OpenGL + EGL and AO46 entirely from userspace.

Vulkan applications: use standard Vulkan through the normal Khronos loader, with AVK143 acting as the driver.

The important part is that disabling macOS security features becomes an optional cost of legacy transparent compatibility, rather than something everyone has to do just because they want to test the driver.

That was a fairly obvious architectural smell in hindsight. If a brand-new application is already willing to target your modern driver stack, forcing it through a deprecated Apple OpenGL ABI and then asking the user to weaken system security so you can replace that ABI is just needless baggage.

So this doesn’t magically make the legacy replacement path disappear, and I’m not claiming that old binaries suddenly work without any system-level interception.

But it does mean that AO46 itself no longer needs to be architecturally tied to SIP/AuthRoot being disabled, and AVK143 shouldn’t need that installation model at all.

For people who just want to build against the driver, test it, develop games/tools on it, or experiment with modern OpenGL/Vulkan on macOS, the intended path can now be a normal userspace installation.

That removes one pretty large “this looks cool, but I’m not disabling half of macOS security to try it” barrier from the project.

• RGB32 buffer views now support real FLOAT, UINT, and SINT variants through live sampler state, with the unsigned path retaining hardware draw/readback coverage.
• GL 4.3 groundwork now includes static-index SSBO atomics lowering through Mesa and executing a fenced 32-thread atomic-add verification.

The adapter now exposes public MTLBuffer.gpuAddress, validates and writes pointer roots, and the poly smoke executes Mesa’s real prefix-sum tessellation MSL, verifying counts, heap allocation, generated index-buffer address, and indirect draw data.

This removes the GPU-root blocker for the Metal Gallium driver’s next feature gate: reaching a functional OpenGL 4.0 context on the way toward AO46’s final OpenGL 4.6 target.

What remains for that GL 4.0 gate is full TCS support, tessellation-kernel completion, TES, and final render execution.

After a few weeks of pushing AO46 much further than I originally expected, I think I’ve finally reached the point where continuing the same reverse-engineering path would cross from graphics-driver research into territory I’m not comfortable touching on real machines.

For context, AO46 started as an attempt to replace Apple’s deprecated OpenGL stack with a modern OpenGL 4.6 implementation on macOS.

The project has already moved through several architecture stages:

• replacing the old OpenGL.framework-facing stack,
• Mesa/Gallium integration,
• NIR,
• Asahi’s AGX compiler/backend work,
• macOS-specific resource management,
• GPU queue/submission tracing,
• and finally following the path between Apple-generated GPU code and the actual executable GPU mapping used by the kernel driver.

For quite a while I assumed the remaining problem was simply:

“figure out how macOS submits the same AGX command buffers that Asahi submits on Linux.”

It turns out that was too simple.

What the reverse pass has increasingly shown is that Apple does not treat executable GPU code as just another buffer with a magic flag.

There is a fairly clear trust boundary.

Very roughly, the path looks like:

Apple GPU compiler output
        ↓
Apple-owned code resource
        ↓
private relocation / preparation step
        ↓
restricted executable GPU mapping
        ↓
queue consumption

Generic buffers do not appear to just become executable after the fact.

And the important bit is that the transition into that executable mapping is not exposed like a normal public allocation API.

At this point, the remaining work would mean investigating the enforcement side of that boundary rather than merely understanding the graphics ABI around it.

That is where I’m stopping.

Not because the project suddenly became impossible, but because there is a difference between:

reverse engineering an undocumented graphics driver

and

deliberately trying to defeat a platform security boundary in order to make arbitrary GPU memory executable.

The latter is not something I want AO46 to become.

And honestly, that boundary existing is probably a good thing.

So is AO46 dead?

No.

Not even remotely.

A huge amount of useful architecture now exists that did not exist a few weeks ago.

The project now has concrete implementations/documentation for:

• OpenGL.framework replacement
• CGL/NSOpenGL compatibility
• Mesa Gallium integration
• NIR shader pipeline
• AGX compiler integration
• macOS BO/resource handling
• synchronization/fence ownership
• queue tracing
• Apple GPU submission structure analysis
• Apple compiler-object parsing
• executable-code provenance tracking

The original project was basically:

OpenGL
 ↓
Mesa
 ↓
Metal

The current research has gone much deeper:

OpenGL
 ↓
Mesa
 ↓
Gallium
 ↓
NIR
 ↓
AGX backend
 ↓
macOS GPU infrastructure

That is still extremely valuable.

What we do not currently have is a legitimate way to complete the final transition:

Mesa-generated AGX code
        ↓
???
        ↓
Apple-authorized executable GPU mapping

And fabricating or bypassing that transition is exactly the point where I’m drawing the line.

Interestingly, this also answers one of the biggest questions people kept asking

A lot of people assumed the blocker would be:

• AGX ISA differences,
• WindowServer,
• Metal interoperability,
• command buffer encoding,
• or simply “Apple doesn’t expose IOKit.”

Those are all problems.

But they were not the final one.

The deepest blocker is much more architectural:

Apple owns the transition that turns compiled GPU code into something the GPU is actually allowed to execute.

That is a considerably stronger boundary than I expected when this project started.

What happens next?

Probably one of three directions.

1. Stay above the protected execution boundary

Use Apple-supported APIs for the final executable-code handoff while keeping as much of Mesa/AGX/OpenGL outside that boundary as possible.

This is currently the most realistic direction.

2. Continue documenting the architecture

There is still a huge amount of useful work that can be done without trying to bypass anything.

For example:

• command submission structures
• resource lifetime rules
• synchronization semantics
• shader metadata
• queue behavior
• compiler object formats
• AGX generation differences

All of that is legitimate reverse-engineering work and could be useful far beyond AO46.

3. Wait for a better supported interface

Apple may eventually expose more GPU infrastructure through DriverKit, Metal evolution, or some future API.

If a legitimate executable-code path appears, AO46 can plug into it.

The upper 90% of the architecture would not need to be thrown away.

Honestly, I’m pretty happy we found this

This might sound weird, but discovering a hard architectural boundary is actually a useful result.

A month ago the unanswered question was:

“Can Mesa/Asahi actually talk to Apple’s GPU stack on macOS?”

Now the question is much narrower:

“How can externally generated AGX code legitimately enter Apple’s trusted executable-code pipeline?”

That is a much better-defined problem.

And importantly, we now know where not to push.

So for now the project is stepping back from the protected execution path and focusing on everything around it.

AO46 is still alive.

The research path just finally reached a sign that says:

            ┌─────────────────────────────┐
            │   HERE BE SECURITY POLICY   │
            │                             │
            │ graphics engineers pls stop │
            └─────────────────────────────┘

Which, considering how absurdly deep this project has gone in three weeks, was probably inevitable.

Finally , after hours of discussion with my university friends ...... We reached a successful workflow plan regarding the final weeks of OpenGL System Framework for MacOS project

We found out the exact loophole after hours of reverse engineering Apple's System Internals after the post regarding the pivot from Mesa--->Metal---->AGX to Mesa--->Asahi---->AGX

During reverse engineering , we hit lots of blockers ....... we were feeling that an enormous amount of workload will come when we would design a MacOS winsys from months of reverse engineering which may develop into years ........... Everyone after hours was literally hopeless

Then I told everyone to stop for an hour and brainstorm , and we thought for those 60 minutes various techniques . The main issue was simple .... we had literally less documentation for macOS itself , because Asahi had done that for linux majorly , even though some tools like libwrap.dylib where there , but that was not the final solution

Then my friends finally struck the idea which has really changed the direction of this project and that now we can actually think of project completion , bug sweeps and the major thing --> Khronos CTS test

He told us that when OpenGL requires Winsys on MacOS/DRM on Linux , then Apple must have already designed one which Metal uses .... Now some may argue that its heavily tied to Metal ..... BUT THE REAL ANSWER IS ACTUALLY NO , because Metal , Vulkan , OpenGL,DX12,... All are graphics APIs , Metal maybe highly optimised for Apple Silicon Arch .... that doesn't imply in driver engineering sense that the Winsys / DRM has to be tied to that graphics API , it simply helps the low level kernel drivers to understand the GPU machine code and finally send the work to the GPU registers/ALU/RT Cores whatever u say , in this case that is the AGX IOKit UABI , and Apple has one which helps Metal encode high level instructions to lower level IOGPU instructions which actually the Apple M-Series and A-Series chips understand [Fk Apple Logic :Metal Speaks directly to the GPU 💀😑]

So now due to the help of our friend .... our reverse engineering sessions have decreased by a magnitude ...... the only thing we still have to Analyse and target is the exact C contracts Metal uses to communicate with the UABI , thus letting us make a small , niche but very critical Obj-C bridge that Mesa/Asahi would use to speak to the AGX UABI ....

You can even think this in the linux sense in a hypothetical sense where someone is making Metal drivers for Linux ,more or less , in every OS , a pass comes which is independent of Graphics APIs ..... the driver/bridge(which we call winsys and in linux land is handled using DRM) that lets the API speak to the kernel and eventually the GPU ALU/Register , they would also make a small bridge and make that sent the required contracts , in Linux its magnitude easier because of Open Source Behaviour , but eventually on MacOS , the bridge has become right now the full final centre core of the whole project now

Finally , lets hope for the best now , because apparently when people would use OpenGL on Mac. they wouldn't want to see how their shaders are getting encoded in Minecraft , they would obv wanna see more shinier puddles 😉

For the last 2–3 days I've been staring at the lower half of the OGL46 OSX architecture and reconsidering a decision that made perfect sense when I started the project, but increasingly feels like the wrong final destination.

First, an important clarification about what the project is for new people checking the project

The project was never supposed to be:

Application
    ↓
Some independent OpenGL implementation
    ↓
Metal

running somewhere beside Apple's existing OpenGL stack.

The original idea was much more invasive and much more interesting.

macOS already has decades of OpenGL-facing infrastructure:

OpenGL.framework
CGL
NSOpenGL
pixel format/context semantics
existing application ABI expectations
existing OpenGL-linked binaries

The problem is that the implementation underneath that system surface was effectively frozen around OpenGL 4.1.

So AO46's original architecture was to retain and intercept that application-facing ecosystem while replacing/redirecting the implementation beneath it.

Conceptually:

Existing macOS OpenGL Application
                │
                ▼
        OpenGL.framework
       replacement/redirect
                │
                ▼
        AO46 framework layer
                │
        ┌───────┴────────┐
        │                │
   AO46Runtime       AO46 CGL
        │                │
        └───────┬────────┘
                ▼
             Mesa
                │
        OpenGL state tracker
        GLSL compiler
        Gallium
        NIR
                │
                ▼
         AO46Metal backend
                │
                ▼
              Metal
                │
                ▼
          Apple AGX GPU

There were also lower framework/runtime pieces around this model such as the ICD/client/runtime separation, with components along the lines of:

OpenGL.framework interception
        ↓
OpenGL_4.6.framework
        ↓
libGL / ICD layer
        ↓
AO46Runtime / CGL
        ↓
Mesa
        ↓
backend driver

So the idea was not:

>

It was almost the opposite.

The existing Apple OpenGL-facing infrastructure was useful because applications already expect it.

Rather than forcing every application to retarget itself against some new wrapper library, AO46 could preserve the expected macOS OpenGL entry path and replace the old implementation underneath.

That was one of the main reasons I liked this architecture in the first place.

Where the original lower backend came in

Originally, once AO46 had redirected execution into Mesa, the lower path was supposed to look roughly like this:

OpenGL application
        ↓
Apple-compatible OpenGL.framework entry
        ↓
AO46 CGL/runtime
        ↓
Mesa OpenGL
        ↓
Gallium / NIR
        ↓
AO46Metal
        ↓
Metal
        ↓
AGX

This was already substantially different from something like MoltenGL-style application retargeting.

The application still speaks OpenGL.

Mesa still provides the modern OpenGL implementation.

AO46 handles the macOS framework/runtime/context side.

Metal was simply the hardware execution backend.

And for getting the project moving, this architecture made a lot of sense.

Metal gives you:

documented GPU access
resource management
command queues
pipeline creation
synchronization
shader compilation
Apple Silicon support

without needing to implement an entire native GPU userspace stack on day one.

But after working further down the driver and thinking about the architecture for the last few days, I kept coming back to one slightly uncomfortable question:

Why should Metal remain the final backend?

Because the lower path currently becomes:

GLSL
 ↓
Mesa
 ↓
NIR
 ↓
AO46 Metal lowering
 ↓
Metal representation
 ↓
Apple Metal compiler
 ↓
AGX ISA
 ↓
GPU

Mesa has already reduced the OpenGL program into a hardware-oriented representation.

Then AO46 converts that into another high-level graphics API.

Then Apple's compiler converts that back down toward the actual AGX hardware.

It works.

But architecturally, there is still another abstraction layer sitting between Mesa and the GPU.

And then the obvious monster sitting in the room finally became difficult to ignore:

Asahi already has a native Mesa backend for this GPU.

So AO46 is entering another development phase

I'm now experimenting with pivoting the lower-level side of AO46 away from:

Mesa
 ↓
AO46Metal
 ↓
Metal
 ↓
AGX

toward:

Mesa
 ↓
Asahi
 ↓
AGX

The important word here is lower-level.

I'm not throwing away the original framework architecture.

The system-facing design remains:

existing OpenGL application
        ↓
macOS OpenGL.framework interception/replacement
        ↓
AO46 OpenGL 4.6 framework
        ↓
AO46Runtime / CGL / ICD
        ↓
Mesa OpenGL

That part is actually one of the strongest parts of the design.

The redevelopment begins after Mesa/Gallium/NIR.

So the new architecture I'm exploring looks more like:

┌─────────────────────────────────────────────┐
│ Existing macOS OpenGL application           │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ OpenGL.framework interception / redirect    │
│ Existing macOS GL-facing ABI                │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ AO46 OpenGL_4.6.framework                   │
│ AO46Runtime                                 │
│ CGL / contexts / pixel formats / drawables  │
│ ICD / client routing                        │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ Mesa OpenGL 4.6                             │
│                                             │
│ OpenGL state tracker                        │
│ GLSL compiler                               │
│ Gallium                                     │
│ NIR                                         │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ Asahi Gallium Driver                        │
│                                             │
│ NIR lowering                                │
│ AGX resource layouts                        │
│ pipeline construction                       │
│ tiler state                                 │
│ render state                                │
│ command generation                          │
└────────────┬────────────────────┬───────────┘
             │                    │
             ▼                    ▼
     AGX shader compiler      AGX state/
             │                commands
             ▼                    │
          AGX ISA                 │
             │                    │
             └──────────┬─────────┘
                        ▼
                AGX command stream
                        │
                        ▼
              AO46 macOS AGX winsys
                        │
                        ▼
                 macOS AGX UABI
                        │
                        ▼
            Apple kernel GPU stack
                        │
                        ▼
                  AGX firmware
                        │
                        ▼
                    Apple GPU

And THIS is the part that makes the new direction feel like the cherry on top of the original project rather than a completely different project.

The old architecture wasn't wrong

This is important.

The Metal backend wasn't some terrible mistake that suddenly needs to be deleted from history and buried in /dev/null.

It solved a very real bootstrap problem.

Originally AO46 had two huge challenges:

1. Replace/extend Apple's obsolete OpenGL implementation

2. Actually execute modern GL workloads on Apple Silicon

Mesa solved a large part of problem #1.

Metal gave me a realistic answer to problem #2.

So the first-generation architecture naturally became:

Apple OpenGL-facing system
        ↓
AO46 replacement/runtime
        ↓
Mesa
        ↓
Metal
        ↓
GPU

That got the architecture off the ground.

But now that the upper stack is becoming much clearer, the question has changed.

Instead of:

>

I'm increasingly thinking:

>

That's the pivot.

The Asahi path changes what AO46 actually becomes

The Metal design makes AO46 roughly:

>

Still cool.

But the proposed Asahi path makes it closer to:

>

That is a very different beast.

The final execution path changes from:

OpenGL
 ↓
AO46
 ↓
Mesa
 ↓
Metal
 ↓
AGX

to:

OpenGL
 ↓
AO46
 ↓
Mesa
 ↓
Asahi
 ↓
AGX

while the application-facing architecture does not change.

An existing application could still enter through the same OpenGL/CGL-facing environment it expects.

It does not need to know:

Mesa exists
Asahi exists
AGX exists

It just thinks:

glDrawElements(...);

and somewhere very, very far underneath that innocent little function call, several million lines of accumulated graphics-driver pain occur.

As nature intended.

Why Asahi is especially attractive here

The really interesting thing isn't merely that Asahi contains an AGX shader compiler.

If all I wanted were:

NIR → AGX shader ISA

this idea would be much less exciting.

The bigger deal is the Asahi Gallium driver itself.

It already understands how to translate Gallium's hardware-facing state into Apple GPU concepts:

Gallium draw calls
        ↓
AGX pipeline state

Gallium resources
        ↓
AGX resource layouts

NIR
        ↓
AGX compiler

framebuffer state
        ↓
AGX render targets

draw state
        ↓
AGX tiler/render commands

So instead of AO46 independently maintaining:

Mesa → Metal state mapping

the eventual target becomes reusing:

Mesa → AGX state mapping

which already exists because that is literally what Asahi was designed to do.

The one major missing piece

And hilariously, this redesign makes the remaining problem much easier to describe:

Asahi userspace
       ↓
   ????????
       ↓
macOS AGX kernel driver

Asahi normally runs through its Linux-side kernel interface.

AO46 is running on native macOS.

So the new experimental lower component would be something like:

AO46AGXMac

or:

AGXMacWinsys

whose responsibility is not OpenGL.

Not GLSL.

Not NIR.

Not tessellation.

Not geometry shaders.

Not blending.

Not shader compilation.

Its job is the ugly OS/device boundary:

buffer objects
GPU virtual addresses
memory mapping
contexts
queues
synchronization
command submission

essentially replacing the Linux-specific bottom of the Asahi path with a macOS-specific one.

Conceptually:

                 Asahi Gallium
                       │
                       ▼
              AGX command stream
                       │
          ┌────────────┴────────────┐
          │                         │

      Asahi Linux                AO46 macOS

          │                         │
          ▼                         ▼
      DRM winsys              AGXMac winsys
          │                         │
          ▼                         ▼
    Linux AGX UAPI            macOS AGX UABI
          │                         │
          └────────────┬────────────┘
                       ▼
                    AGX GPU

THAT is the actual research boundary now.

And I'm keeping the Metal backend

At least for development, removing AO46Metal would be throwing away something extremely useful.

The architecture can instead become:

                  AO46
                   │
        OpenGL.framework / CGL
                   │
               AO46Runtime
                   │
                  Mesa
                   │
            Gallium / NIR
                   │
          ┌────────┴────────┐
          │                 │
          ▼                 ▼

      AO46Metal          AO46AGX
          │                 │
        Metal             Asahi
          │                 │
          ▼                 ▼
         AGX               AGX

The Metal backend becomes:

stable/reference path

while the AGX backend becomes:

native/experimental path

And having both could actually be incredibly useful during driver development.

Run the same GL workload through:

                   Mesa/NIR
                      │
             ┌────────┴────────┐
             ▼                 ▼
          Metal              Asahi
             │                 │
             ▼                 ▼
            AGX               AGX
             │                 │
             └────────┬────────┘
                      ▼
              compare results

That gives me a reference for:

shader output
framebuffers
depth/stencil
blending
compute
SSBO behavior
atomics
barriers
geometry
tessellation

while the native backend is being developed.

So the old backend doesn't become wasted work.

It becomes the reference implementation for the new one.

Which is actually a nicer outcome than I originally expected.

So this isn't really AO46 changing direction

It's AO46 going one layer deeper.

Phase one was essentially:

Replace the frozen OpenGL implementation
while retaining macOS's established
OpenGL-facing application environment.

Phase two was:

Use Mesa to provide modern OpenGL
and execute it through Metal.

And now the next experimental phase is:

Keep the same interception/framework/runtime/Mesa design

BUT

replace the final Mesa→Metal execution path
with Mesa→Asahi→native AGX.

So the project evolves from:

Apple OpenGL surface
       ↓
AO46
       ↓
Mesa
       ↓
Metal

into:

Apple OpenGL surface
       ↓
AO46
       ↓
Mesa
       ↓
Asahi
       ↓
AGX

That, to me, feels like the actual logical conclusion of the architecture I started with.

The original idea was already to take Apple's abandoned OpenGL system and replace the machinery underneath it.

This just pushes that idea all the way down to the GPU.

And if this path actually becomes viable, the funniest possible outcome is that macOS's old OpenGL-facing infrastructure ends up being used to host a completely new OpenGL 4.6 implementation whose final hardware backend bypasses Metal entirely and talks native AGX.

Which is a significantly better cherry on top than I had planned when I started this thing.

Another major development pass on my OpenGL 4.6 system framework for macOS is complete.

The goal of this project is to replace macOS's outdated OpenGL 4.1 system implementation with a native, Mesa-backed OpenGL 4.6 runtime while preserving the existing macOS OpenGL architecture, including CGL, NSOpenGL compatibility, system framework behaviour, and driver-style dispatch.

This update moved the Mesa-backed OpenGL 3.x/4.x execution path significantly closer to being usable.

Native Metal mipmap generation

The Metal driver now implements real mipmap generation.

This functionality is also advertised through Gallium, allowing Mesa to use the native Metal implementation instead of treating mipmap generation as unsupported or relying on incomplete fallback behaviour.

Texture uploads, mipmap generation, and subsequent textured rendering now successfully pass through the runtime test path.

NIR-to-MSL textured shader fixes

A large part of this update focused on the project's NIR-to-MSL shader translator.

Textured shaders were previously failing when the translator encountered missing NIR instruction sources or could not correctly determine the sampler and texture index.

The translator now includes:

• Null-source guards for incomplete or optional NIR sources
• Sampler-index fallback handling
• Static texture-index resolution
• Direct mapping from texture_index to Metal [[texture(i)]] bindings
• Texture binding behaviour consistent with the existing Metal backend

This fixes the major shader translation issue that previously caused textured draw calls to fail before reaching Metal successfully.

Correct OpenGL program deletion behaviour

The runtime compatibility test was also corrected to follow Khronos program-deletion semantics.

Calling glDeleteProgram does not necessarily destroy a program immediately if it is still bound as the current program. The test now unbinds the program before expecting:

glIsProgram(program) == GL_FALSE

This removed a false failure from the runtime test and brought the behaviour in line with the OpenGL specification.

Pbuffer changes

Pbuffer-backed drawables are now forced onto a single-buffer path.

This improved the pbuffer execution flow, although one pbuffer-related failure still remains.

Current verification status

Both build configurations compile cleanly.

NSOpenGL compatibility testing now passes completely.

The main runtime compatibility test now successfully passes through:

• Buffer object creation and data operations
• Texture creation and uploads
• Native Metal mipmap generation
• Shader compilation
• Program linking
• NIR-to-MSL translation
• Texture and sampler binding
• Textured draw execution
• OpenGL program deletion semantics

The only remaining failing check is:

>

The failure boundary is now isolated to the pbuffer import and synchronization path. The next development pass will therefore focus specifically on drawable-to-texture synchronization rather than the core OpenGL, Mesa, or shader compiler paths.

The project has effectively moved from textured shaders failing during translation to completing textured rendering and stopping at one isolated pbuffer synchronization test.

Still plenty of work ahead, but the native Mesa-to-Metal OpenGL 3.x/4.x path is now considerably more functional than it was before.

Pushed a fairly substantial cleanup pass in CryptEX v0.6.4.

The main focus in this update was not “new feature for the sake of it”, but tightening the parts that tend to cause the worst user experience in small-network / mixed-platform testing:

- backend path recovery for the GUI/client flow

- better peer convergence when nodes are on competing equal-height tips

- unified mining behavior so GUI and backend mining stop drifting through separate local chain state assumptions

- stronger release coverage across platforms, now including Linux x86_64 and Linux ARM64 artifacts alongside macOS and Windows

A few concrete things that changed:

1. Backend startup recovery

The desktop client is now more defensive about stale or development-only daemon paths. If a saved backend path is missing or clearly points at a transient build artifact, the client recovers to the bundled daemon path instead of just falling over into backend-startup failure.

2. Peer sync / fork convergence

A lot of effort went into the equal-height fork problem and “why are these two nodes not resolving themselves?” class of bugs.

The networking side now does a better job of:

- tracking peer-announced heights

- requesting headers earlier

- using incoming headers to infer remote chain progress

- avoiding useless rebroadcast behavior when a block doesn’t actually advance the active tip

That matters because the failure mode wasn’t just “bad block rejected”, it was also nodes idling on competing views for too long without enough signal to converge cleanly.

3. Unified mining path

Mining behavior is now aligned around the live backend chain state rather than letting different entry points behave like they own separate local truth.

That sounds obvious, but it removes an entire category of confusion where a miner can be “working” from its own perspective while the actual chain manager rejects the result because the state basis was stale, repaired, or simply not the active tip anymore.

4. Better release matrix coverage

The 0.6.4 release now has:

- macOS ARM64

- Windows x86_64 bundle

- Linux x86_64

- Linux ARM64

For Linux, both raw binaries and AppImage packaging are included. The external PoW worker path is also carried across platforms, with the dedicated low-level worker variants kept outside consensus logic.

5. Checksum / release artifact cleanup

The release checksum manifest was also refreshed so the published assets line up with the current payload.

What’s next:

- more native Linux validation, especially AppImage runtime behavior on real target machines

- continued sync-path hardening in small or sparse peer topologies

- more cleanup around release/runtime consistency so platform builds behave closer to identically from the user side

- continued work on keeping miner performance improvements isolated from consensus correctness

The main goal here is simple: fewer “it runs but doesn’t actually converge” situations, and less ambiguity between what the miner thinks is valid and what the node will actually accept.

I am sharing a speculative scientific note proposing a first-principles framework called Recursive Ontology, where reality is not assumed to begin from fixed spacetime, particles, dimensions, or universal physical laws.

The central idea is that every apparent framework, such as a universe, geometry, coordinate system, or physical law-system, may itself emerge from another deeper framework while also generating further lower-level frameworks. In this model, there is no absolute smallest scale, largest scale, fundamental point, or final “base layer” of reality.

The paper introduces the Hypervoid as an abstract placeholder for undefinable recursive possibility, not a physical space or higher-dimensional container. It also defines two conceptual operators:

Zoom Operator (Z): moves inward or outward along a recursive chain of frameworks.

Jump Operator (J): moves between independent recursive branches that do not share a universal embedding space.

The note argues that concepts like distance, probability, dimensionality, and physical constants may only be locally meaningful inside a given recursive framework. From this view, the Big Bang is interpreted not as an explosion into pre-existing space, but as the emergence of a stable spacetime framework from a deeper recursive structure.

This is not being presented as confirmed physics. It is a speculative ontology and mathematical-physics proposal. The goal is to explore whether such a framework can be formalized using tools such as category theory, operator algebra, emergent geometry, and eventually tested through possible deviations from standard physics or cosmological signatures.

Feedback is welcome, especially on mathematical consistency, possible formalization, and whether the Zoom/Jump operator structure can be made rigorous.

One of the more useful maintenance updates I’ve worked on recently was not a new mining algorithm or a UI feature. It was removing an architectural mistake: the GUI miner and the backend node were not actually operating on the same chain state.

The old model had a separate miner-side local chain flow. That created exactly the class of bugs you’d expect from duplicated state:

• GUI miner could drift from the backend chain
• locally mined block replay became a thing
• wallet state and mining state could disagree
• chain repair logic had to compensate for stale local tails
• valid PoW could be found on top of state that the real backend would later reject

So the latest update was basically a control-plane cleanup:

• the GUI miner now mines through the live backend RPC session
• the CLI mine command also supports the same RPC-backed path
• both now use the backend as the single source of truth for chain state

The important part is what changed operationally.

Instead of the miner opening its own local Blockchain view and building blocks there, the miner now does:

1. ask the backend for a template with getblocktemplate
2. hand the header/target to the external PoW worker
3. submit the candidate block back with submitblock

That sounds simple, but it removes a lot of ambiguity.

Now the wallet, the GUI dashboard, the node, and the miner are all observing and mutating the same chain state. There is no second “shadow chain” for the GUI miner to maintain.

The external worker architecture stayed the same on purpose.

The PoW worker still only does nonce search. It does not define consensus. It gets:

• an 80-byte header
• a 64-byte expanded target
• nonce search bounds

and returns:

• found / not found
• nonce
• iterations
• resulting hash

Consensus still stays entirely inside the daemon. That boundary turned out to be the right one.

This update also let me remove some ugly glue that only existed because of the split model:

• no more GUI-side mined block re-submission from stdout parsing
• no more replay/reconciliation loop for locally stored mined blocks
• no more default dependence on a separate gui-miner blockchain state

A lot of the recent chain bugs became easier to reason about once that separation was enforced.

For example, the recent failures were not really “the assembly miner is broken” failures. They were mostly one of these:

• stale local chain metadata
• missing canonical block persistence
• activation path inconsistencies
• valid candidate block found against an out-of-date local template

Once mining was forced through the backend RPC path, those bugs became much easier to isolate because the worker path and the consensus path were no longer muddying each other.

The other useful change was better rejection diagnostics.

Previously, a block found by the worker could just come back as “stale or invalid”, which is almost useless when you’re debugging. Now the node can distinguish things like:

• stale parent
• changed expected bits
• activation/path issues
• valid tip extension that still failed to become persisted active state

That last category was especially important, because it exposed that some failures were happening after validation, inside chain activation/persistence, rather than in PoW or block assembly.

So the short version of the update is:

• mining control path is now unified
• the backend owns chain truth
• workers only do work, not state
• the GUI no longer runs a second blockchain by accident
• debugging got much better because rejection reasons are now explicit

What I’m planning to work on next is mostly about hardening the parts this change exposed.

Main items:

1. Legacy datadir migration There are still old gui-miner folders from earlier runs. New mining sessions don’t rely on them anymore, but I want a proper one-time migration/cleanup path so older installs don’t keep confusing people.
2. Chain activation and persistence invariants The biggest class of subtle bugs now is no longer “bad hash” or “bad target”. It’s “valid block, but active chain bookkeeping/persistence drifted”. I want tighter invariants and regression tests around:
   • active tip updates
   • canonical height-file persistence
   • reload/restart behavior after recent tip changes
3. Better mining job invalidation Right now stale-template detection is much better, but I still want cleaner cancellation semantics so worker jobs get retired immediately when:
   • tip changes
   • expected bits changes
   • a competing accepted block makes the current template obsolete
4. Wallet state clarity There was a lot of confusion around locked vs immature vs approval-gated funds. The logic is better understood now, but the UI and RPC output should make those states much more explicit.
5. More consensus vectors and miner differential tests The worker/daemon split is in the right place now, so the next step is broader automated coverage:
   • template-to-worker-to-submit round trips
   • stale-template rejection tests
   • compact target canonicalization vectors
   • more cross-platform worker correctness checks
6. Difficulty model behavior under edge conditions There has already been work on damping and emergency recovery behavior, but I still want better observability and more test coverage around:
   • post-recovery behavior
   • timestamp edge cases
   • oscillation resistance under low-hashrate conditions

That’s the update in a nutshell. Not flashy, but probably more valuable than a flashy feature would have been. A lot of reliability work is really just deleting alternate sources of truth.

If anyone else has dealt with GUI/node/miner split-state problems in a desktop crypto stack, I’d be interested in how you handled:

• single-source-of-truth chain ownership
• worker/job invalidation
• mined block submission boundaries
• migration away from legacy local miner state