NootRX: a kext that makes unsupported AMD rDNA 2 cards work on macOS

The problem is a discrete GPU macOS refuses to enumerate

The README describes the project in one line as the unsupported AMD rDNA 2 dedicated GPU kext. Unpack that. macOS ships with support for a fixed set of graphics hardware, and an AMD card of the rDNA 2 generation is outside it. On a Hackintosh, the symptom is that the card is present in the machine but the system does not drive it, and the usual outcome is a black screen with no usable display output through that adapter.

NootRX exists to close that gap with a kernel extension, which is the mechanism macOS offers for extending hardware support in ways the vendor never shipped.

The topic tags pin down the target hardware more precisely than the README does: amd, amd-gpu, amdgpu, rdna, rdna2, dgpu, dedicated-gpu, dedicated-graphics, navi, and specifically navi21, navi22 and navi23, which are the rDNA 2 part names. The tags also carry lilu and lilu-plugin, plus lilu's own ecosystem markers like macos, macosx, osx and hackintosh, which tells you both the platform and the architecture of the solution.

So the audience is specific: people running macOS on Intel Macs who have fitted, or want to fit, an AMD discrete GPU from the rDNA 2 generation and need the machine to drive it. Nobody else has a reason to install this.

Lilu is the dependency, and the tree ships it as a submodule

The top level entries show a small repository with a clear shape: a LICENSE.md, README.md, the NootRX.xcodeproj/ directory, the NootRX/ source directory, a Scripts/ directory, and two submodule references, Lilu and MacKernelSDK, alongside .gitmodules, .clang-format and a .github directory.

Lilu is the kext loading framework this project plugs into, and the lilu-plugin tag in the repository confirms the relationship. MacKernelSDK is the SDK the extension is compiled against. Both are present as submodules rather than as vendored copies, which is a deliberate choice with two consequences: the build always compiles against the version of the SDK the maintainer pinned, and a clone without submodule initialisation will not build at all.

The credits section names Acidanthera for the UnfairGVA patches in WhateverGreen. That is the more interesting dependency in practice, because WhateverGreen is a separate and better known kext in the same macOS hardware community, and its graphics patches are where the code for patching graphics behaviour under macOS already lives. NootRX builds on top of that work rather than reinventing it.

The overall pattern is worth naming: this is not a standalone driver. It is a Lilu plugin that expects a particular kext ecosystem to be present, which is exactly how the wider Hackintosh tooling is assembled.

Building means the Xcode project and two submodules

There is no install command in the README, and there is no documented build procedure either. What the repository gives you are the inputs for the build: an Xcode project, a source directory, a scripts directory and a clang-format configuration.

The practical sequence, for someone who knows the macOS kext toolchain, is: fetch the repository with its submodules so that the Lilu and MacKernelSDK trees are present, open NootRX.xcodeproj in Xcode, and build. The Scripts/ directory is where project specific helper steps live, and the .clang-format file tells you the code style the maintainer expects in contributions. The GitHub Actions workflow referenced by the badge in the README title, main.yml on the master branch, is the automated counterpart of a local build, so its status is the quickest signal that the tree currently compiles.

The README contains no shell commands, so there is nothing to copy for the build. The one block it does fence is the licence header, reproduced here exactly as it appears, and it is worth reading before you build anything from this tree.

Licensed under the ChefKiss Open Knowledge License version 1.
This work is licensed to you under the terms of the ChefKiss Open Knowledge
License, either version 1 of the License, or (at your option) any later
version published by ChefKiss.
This work may not be used to train or develop artificial intelligence,
and may not be used with artificial intelligence in any other way. See
the ChefKiss Open Knowledge License for details.

For the first actual use, the install instructions live off the repository. The README points to the project page at chefkiss.dev/applehax/nootrx and to the repository issues for more information, and the project description gives the same homepage. The README also notes the project is under active research and development, with some minor issues expected.

The honest summary for a newcomer: this is a build it yourself project. There is no binary to download, no release to fetch and no script that installs anything, which is normal for kexts of this kind but means the first hour is spent on the toolchain rather than on the feature.

The licence is unusual, and its AI clause is deliberate

The licence deserves more attention than it usually gets in a review, because it is not a standard one. GitHub classifies it as Other, a custom licence it cannot categorise, and the README quotes the licence header in full.

The work is licensed under the ChefKiss Open Knowledge License version 1, with the header allowing version 1 of the licence or, at the option of the user, any later version published by ChefKiss. It carries the usual warranty disclaimer, that the work is distributed in the hope that it will be useful but without any warranty.

The distinguishing clause is the one about artificial intelligence: the work may not be used to train or develop artificial intelligence, and may not be used with artificial intelligence in any other way. The README title also carries a badge stating that it was written by humans, not by AI.

Two things follow. First, this is not an OSI approved licence, so a company with an open source policy may need an exception for it, and the full text at git.chefkiss.dev is the document that governs, not the header in the README. Second, the restriction cuts across the usual expectation for a driver project, and it applies to how you use the code rather than to what the code does. Anyone whose workflow involves AI tooling of any kind needs to read that clause carefully before pulling this into a repository.

This review describes the clause and does not interpret it legally.

The maintainer calls it research, not a finished product

The README carries a note that is easy to skim past and useful to quote, because it sets expectations more honestly than the project description does. It says the project is under active research and development, that there will be some minor issues here and there, but that it is almost perfectly functional. It also says to see the repository issues and the project site for more information.

That phrasing tells you two things. The work is not finished, and the project expects the issues tracker to be the primary channel for problems rather than a formal support process. For a kernel extension that patches graphics hardware, an issues tracker is where a broken display output on a particular card model would surface, and where you would look before attempting the build.

The description itself, the unsupported AMD rDNA 2 dedicated GPU kext, is deliberately blunt about the support boundary. Nothing in the README claims Apple support, nothing claims a warranty of compatibility with macOS updates, and nothing describes a testing matrix across macOS versions.

That last point is the one to keep in mind. A kernel extension operates at a low level in the operating system, and macOS versions change what a kext is allowed to attach to. The repository has no release history to correlate with macOS releases, so a reader cannot tell from the tree which macOS versions the current source is expected to work on. The project page and the issues tracker are the only places that answer would come from.

No releases means you track a commit, not a version

The repository has no GitHub releases at all. The default branch is master, the last push was on 2026-10-10, and the repository is not archived.

For a project whose output is a compiled kernel extension, the absence of tagged releases means the versioned unit is a commit. If you build from the tip, you get whatever the tree contained on that day, and there is no release note telling you what changed between two points in time.

That is not unusual for this corner of the macOS tooling world, where kext projects are often consumed by cloning and building, but it has a cost that shows up when something breaks. The usual workflow becomes: note the commit you built from, reproduce the problem at that commit, check the issues for a fix, and rebuild. The project page at chefkiss.dev/applehax/nootrx and the issue tracker are the two places where that information lives.

The repository also has a Scripts/ directory and a GitHub Actions workflow, so the build itself is reproducible in principle. What is missing is the packaging layer around it: no signed or unsigned binary distribution, no version metadata embedded in a downloadable artifact, no changelog file in the tree.

Licence wise, the distribution file at the root is LICENSE.md, distinct from the README's quoted header, and the header points to the canonical text hosted at git.chefkiss.dev under the ChefKiss/OpenKnowledge repository.

Adding a kext versus choosing hardware that works

The alternative to installing NootRX is not another kext, it is a different decision about the machine. There are two honest routes.

The first is to keep the graphics hardware inside what macOS supports, which for an Intel Mac means the integrated graphics or an AMD or NVIDIA card from a generation Apple shipped drivers for. No kext, no Lilu, no Lilu plugin, and none of the fragility that comes with extending a closed operating system below the level its vendor tested. The cost is that you do not get the particular card you wanted.

The second route is what NootRX takes: keep the rDNA 2 card, and add a kernel extension that teaches the system to drive it, built as a plugin on top of the Lilu framework, borrowing the graphics patching techniques from the WhateverGreen project. The gain is the hardware you actually own or want to buy. The costs are concrete: the dependency chain has to be assembled in the right order, the build needs the macOS kext toolchain, the source tracks a commit rather than a release, and the licence carries a restriction on AI related use that has to be accepted.

Which of these is right depends on the machine and on how much you value the card over the stability of the platform. What NootRX changes is that the option is available at all, and it is worth reading the issue tracker before building to see which cards and which macOS versions people have actually reported working.

Editorial conclusion

Adopt NootRX if you run macOS on Intel hardware with an AMD rDNA 2 card that the system does not recognise, and you are prepared to build the kext yourself, track a source tree that publishes no releases, and accept a licence that restricts how the work may be used. Do not adopt it for a machine with a supported GPU, and do not adopt it if you need an AI related workflow with the code. Verify first by reading LICENSE.md and the ChefKiss Open Knowledge License version 1 text, then by checking the linked page at chefkiss.dev/applehax/nootrx and the repository issues for the current state of support for your specific card.

Frequently asked questions

Official sources

1. ChefKissInc/NootRX on GitHub
2. Issues
3. Project website
4. README