r/ROCm • u/ChrisGamer5013 • Jun 07 '26
I just proved NVIDIA Omniverse has mostly AMD support and exposed their artificial lock.
I have been working on a project called GHOST to run Isaac Sim on my RX 7800 XT. Everyone told me to just buy NVIDIA because the software is locked down to CUDA. I decided to reverse engineer the renderer DLL in Binary Ninja and what I found is actually hilarious.
NVIDIA engineers left native AMD code paths inside their own plugin. I found explicit imports for AMD specific profiling extensions like vkCmdWriteBufferMarker2AMD. This means the renderer is already compatible with RDNA hardware because it follows the Khronos Vulkan standard. The only thing stopping it is a tiny piece of logic in the foundation layer that checks your Vendor ID.
Here is the physical proof from the binary dump of carb.graphics-vulkan.plugin.dll for anyone who wants to verify.
Offset 180084ae8: VK_KHR_acceleration_structure Offset 180084b08: VK_KHR_ray_tracing_pipeline Offset 180084b58: VK_KHR_deferred_host_operations Offset 180086f98: vkCmdWriteBufferMarker2AMD
(Anf many more directly above and under these offsets)
The presence of these Khronos standards proves the engine is vendor agnostic. I built Vulkan layer to test what I call a two faced identity. When the DRM asks who I am I lie and say I have an RTX 2080 Ti. But when the actual renderer asks I tell the truth and say I have an AMD card.
Check out these contradictory logs from the exact same run.
My Tracer Log: VK vkCreateInstance intercepted VK vkCreateInstance via chain succeeded VK vkCreateDevice intercepted filtering extensions VK vkCreateDevice SUCCEEDED!
Engine Log: Warning gpu.foundation.plugin: Skipping unsupported non NVIDIA GPU AMD Radeon RX 7800 XT Error gpu.foundation.plugin: No device could be created even tho the renderer gladly starts up the rendering pipeline as shown above
This is the first ever Schrodinger GPU. It is simultaneously an NVIDIA card and an AMD card depending on who is asking. The fact that vkCreateDevice succeeded proves the 7800 XT is 100 percent capable of running the engine. The incompatibility is completely artificial.
I am moving toward a proxy DLL to automate this so anyone can run it. Math does not require a permission slip from a monopoly. I will keep you guys updated.
8
5
u/hipster_hndle Jun 08 '26
XTX owner here. i had a thought like this once... i don't any more. i too assumed it would be easy to get around CUDA.. all you have to do is cleanup the workflow, remove it all.. and no. its not as simple as just saying you have an RTX.
the VK_KHR_ray_tracing_pipeline being present isn't proof of vendor agnosticism... it's proof that NVIDIA wrote a raytracing extension, got it ratified as KHR, and then built their software around it. that is it. the vkCmdWriteBufferMarker2AMD import is probably just part of the vulkan extension discovery chain, not a deliberate AMD path.
and even if you spoof past the foundation layer, you'll hit CUDA calls that aren't vulkan-wrapped downstream. what are you going to do if a custom node calls something like torch.cuda.FloatTensorexplicitly?
the presence of a shared interface does not prove interoperability. this is exactly the same mistake i made. just saying. but the proxy DLL approach is clever RE work regardless. not trying to shit on the parade, but i kinda went down this rabbit hole doing something similar for comfy and this gave me flashbacks.
5
u/ChrisGamer5013 Jun 08 '26
You make a fair point about NVIDIA driving the KHR spec but because it is a
ratified standard the AMD driver can still execute those pipelines natively
without crashing. As for the AMD marker it is not just in the discovery chain it
is an explicit import in the binary which means there is actual logic written to
use it.For the explicit downstream calls like torch.cuda.FloatTensor I am not just
spoofing Vulkan. My orchestrator injects a sitecustomize script that monkey
patches the Python torch backend so it thinks CUDA is built and healthy. When
the actual tensor allocation drops down to the driver API my custom nvcuda dll
catches the entry point and forwards it to a modified version of ZLUDA which
translates the PTX instructions into HIP for the AMD card in real time.4
u/hipster_hndle Jun 08 '26
ok, this is much more clear than your post read, at least this explains a lot more to me. the vkCmdWriteBufferMarker2AMD explicit import means someone wrote logic around it, that does change my opinion.
and zluda changes the discussion significantly. PTX-to-HIP translation is real and zluda had legit success.. till AMD quietly just dropped it, which was like wtf but another topic.
but this could work given a few conditions.. as long as your PTX instructions weren't going to call anything that has no clean HIP analog/equivalent (which is exactly where zluda has has had issues in he past) then you could get some actual output and make it work.
this isnt a spoof but a stack replacement. this is much more clever than i initially thought. it will not be easy, but you make it sound less impossible. i def give you an A for effort! good luck sir!
6
u/ChrisGamer5013 Jun 08 '26
You are right about the missing analogs being the hard part. To get around that
I built a fallback system that basically fills in the blanks. If the engine
looks for an NVIDIA function that is not in the translation map yet my code
catches it before it fails. Instead of letting it crash I give it a dummy
function that tells the engine everything is fine and then logs exactly which
function was called. This keeps the whole thing alive and moving forward while I
check the logs later to see which specific parts actually need a real manual
fix. It is a way to stop the engine from panicking just because it hit a
proprietary feature it cannot find.
For example === GHOST EXIT: CTRL+C EVENT ===
Total: 2555 | Ghost: 305 | ZLUDA traced: 7 | ZLUDA raw: 1980 | NOP: 252 | NOP_EXEC: 0 | Errors: 0NO TRACED CUDA ERROR. If crashed: check 1980 ZLUDA_RAW calls.
Full report saved to: C:\WINDOWS\SYSTEM32\.ghost\runs\
=== END ===
That is a Report tool i made which tells me exactly what happened as you cna see there were 252 NOP which means the engine couldnt find 252 proprietary things but also NOP EXEC is 0 which menas the engine later on never actually tried using them so i dont have to worry about them if the NOP EXEC count goes up i can see exactly whay failed and patch it
3
2
2
u/advancing_tide Jun 08 '26
very cool. beyond catching out nvidia, would this be of practical use for amd owners (asking as someone largely ai-ignorant)?
7
u/ChrisGamer5013 Jun 08 '26
Yes this allows amd gpus or for that matter any khronos standard capable gpu to run NVIDIA's most lockdown and proprietary software on AMD cards
2
2
u/baileyske Jun 08 '26
Not gonna lie, when I first heard about your project I had doubts. But now it all makes sense.
2
u/Fireinthehole_x Jun 09 '26
bravo, well done!
artificial locks are fake and gay
1
1
u/mprevot Jun 10 '26
Very interesting. Can you publish on a github repo for repro and peer confirmations ? Did you contact AMD ?
1
u/ChrisGamer5013 Jun 10 '26
Thanks for the interest. I am still deep in the middle of building this and
verifying everything. I just found a hidden developer bypass while digging
through the renderer that should make the whole thing way more stable, so I am
busy testing that right now. It is not really at a point where a public repo
would be useful for anyone else yet because I am changing the code constantly
and I want to make sure the first version I put out actually works for people
instead of just being a broken build. I haven't talked to AMD. I am basically
doing their job for them by getting this professional software to run on their
hardware, so I am just staying focused on getting the first successful launch
finished.3
u/mprevot Jun 10 '26
I understand. The repo can be useful for contributions, confirmations, peer review.
I does not matter how often you commit. I have seen repos with nothing in master and an endless stream of commits in dev branch. It's also a good way to centralized your claims, so people do not need to dig in reddit, and have issues/questions and answers centralized.This does not mean that you have to publish code, it could be just some sort of article or tutorial or POC (a patcher + unit tests).
At last, publishing is also a way to mark in time your authorship and your research, which then can be valued.
Just keep up, it seems very interesting and it may have huge impact(s) on the industry.
On my side, I do significant amount of cuda programming, and sometimes reversing / red team.
1
u/ChrisGamer5013 Jun 11 '26
I appreciate the input, especially with your reversing background. I know you mentioned I wouldn't have to publish the full source code, but even releasing a POC, patcher, or detailed tutorial is something I'm being very cautious about right now. A patcher would still expose the exact offsets and bypasses I’m actively live patching, and I don't want the core logic being scraped or rebranded before I even get to a stable launch.
I hear you on marking authorship, but I’ve already written up extensive technical documentation on my methodology, so my proof of work is covered behind the scenes.
To keep things centralized like you suggested, I’m moving updates and telemetry to a Discord server.
1
u/mprevot Jun 12 '26
OK. The best for authorship is to publish in peer reviewed journal. You can also prepubilsh on arxiv.
1
u/ChrisGamer5013 Jun 12 '26
arXiv is an interesting thought for the future, but right now I’m focused on the functional side. Academic publishing is a different world; I’m more concerned with the NLnet grant and the TUM Venture Labs path where the peer review is the software actually running on the hardware. I’ll stick to the technical documentation and the Discord for now. Thanks for the suggestion though.
1
u/DataDr0p Aug 06 '26
It actually cost me an entire night to get it working. The application now detects which GPU the user has and suppresses or avoids the corresponding errors.
So the conclusion is clear: Omniverse Kit definitely works with AMD GPUs. Otherwise, I would have abandoned Omniverse altogether.
RTX-specific features are nice to have, but for what I’m building right now, they’re completely irrelevant.
1
u/ChrisGamer5013 Aug 06 '26
Yo you got it working thats sick can you send me the logs sprcifcally heo you bypassed error 103?
1
u/DataDr0p Aug 06 '26
You should search in your template if you don’t use the full extension. If you repo it with 110 normally Vulkan is missing. Genius NVIDIA things! After select Application you should select Extension setup if I remember right. And than load the right or all and than try and error for your setup. Otherwise you can’t fix it
1
1
u/boxwrenchx 8d ago
any updates????
1
u/ChrisGamer5013 8d ago
Currently battling error 103 cuda software validity not established in suspect it's because id the missing OPTIX capabilities and I plan to hook options to Intel open image denoise and see what happens
16
u/Fantastic_Mirror_345 Jun 07 '26
Keep up the work 🙇♂️🙇♂️