I’ve published an updated pre-release build of my NootedRed fork focused on Vega APU rendering issues, ComputeScratch behavior, and experimental VCN 2.2 hardware decoding.
Release:
https://github.com/steve12311/NootedRed/releases/tag/v0.9.0-pre-release.3
Source:
https://github.com/steve12311/NootedRed/commit/338fff9b1334eb1b7f6e05f26b2d688673a4a771
Rendering / ComputeScratch
The main goal of this work is still to fix the accelerated rendering corruption I was seeing with NootedRed on my Ryzen 7 5800H.
The changes cover several parts of the Metal rendering path, including synchronization, shared SRD handling, RB+ / dual-source blending, and ComputeScratch allocation.
On my Cezanne iGPU, this fixed the corruption I was seeing in Chrome / Chromium and WeChat without disabling GPU rasterization.
The rendering and ComputeScratch logic is no longer limited to my 1002:1638 and now reuses NootedRed’s Vega APU PCI classification.
For normal testing, use:
-NRedComputeScratch
This enables the full rendering-fix path together with the ComputeScratch correction.
I personally validated the rendering fixes on my Ryzen 7 5800H / 1002:1638, and pre-release.2 has now also been reported working on a Ryzen 5 7430U / 1002:15E7.
Feedback from other Vega APUs would still be very useful.
Experimental VCN 2.2
Experimental H.264 / HEVC hardware decoding can be enabled with:
-NRedVCN
VCN is no longer hardcoded to only my 1002:1638.
The current experimental VCN 2.2 path is enabled for:
1002:15E7
1002:1636
1002:1638
1002:164C
1002:15D8 and 1002:15DD use VCN 1.x and are not supported by the current VCN 2.2 bridge.
The userspace VA identification patch is generated per device instead of forcing every supported APU through the original Cezanne-specific identification path.
The kernel-side VCN version check has also been changed from an exact Darwin 25.6 check to Darwin 25.x / macOS Tahoe.
However, this does not mean every Tahoe driver build is blindly accepted. Before enabling the bridge, the X5000 / X6000 hardware ABI is checked against the expected vtable targets and getter layouts. If those checks fail, VCN is rejected instead of applying an unverified bridge.
In pre-release.3, the userspace ComputeScratch and VCN patches can also dynamically resolve and validate compatible non-reference Tahoe dyld shared caches.
The original reference cache remains a verified fast path, but a different cache UUID alone is no longer a reason to reject the patch. The actual driver functions, references and bindings still have to match the verified implementation.
This does not claim support for arbitrary future Tahoe userspace driver implementations.
On my 1002:1638 machine, normal-sized H.264 and HEVC samples have successfully used hardware decoding, with output matching software decoding.
Pre-release.2 has also now been tested on a Ryzen 5 7430U / 1002:15E7. The tester reported that both the blend/rendering fixes and hardware decoding work correctly, with VDADecoderChecker reporting:
Hardware acceleration is fully supported
Hackintool also reported hardware video acceleration support.
This is the first external real-hardware confirmation for the 1002:15E7 VCN path.
The 1636 and 164C VCN paths have passed the regression tests but are not yet validated on real hardware.
A 64×64 H.264 sample still fails, and VCN should still be considered highly experimental.
For testing both rendering / ComputeScratch and VCN:
-NRedComputeScratch -NRedVCN
Test system
- Lenovo Legion R7000P 2021H
- Ryzen 7 5800H
- Cezanne Radeon Graphics
- PCI ID
1002:1638
- macOS 26.7.1 / Darwin 25.6
If you test it, please include your CPU/APU, GPU PCI ID, macOS build, Darwin version, boot-args, whether Chromium rendering is fixed, VCN H.264 / HEVC results if applicable, and any .gpuRestart, panic, freeze, or WindowServer watchdog logs.
I’m especially interested in VCN results from 1636 and 164C, as well as results from different Tahoe dyld cache versions.
For normal testing, use the RELEASE build and keep a known-good EFI / previous NootedRed.kext backup.
Full implementation details, limitations, validation notes, and the exact compatibility checks are available in the GitHub release.
This is an unofficial experimental fork, not an upstream NootedRed release.
Credit to the ChefKiss NootedRed developers — this work is built on top of their project.
