Replies: 1 comment
|
@dayatsin-amd @kentrussell Sorry to bug you guys again, but I have two questions about adding in new platforms;
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello, I'm an intern at the FreeBSD Foundation working with Ed Maste to port ROCm to FreeBSD.
So far we've been able to successfully compile
rocr-runtime, and verified thatrocminforuns without errors, and outputsROCk module is NOT loaded, possibly no GPU devices, then gracefully exits.We've also gotten one patch merged into ROCM/llvm-project to clear compiler blocks on the toolchain side.
As of now, I am working on cleaning up and refactoring my local patches to
rocr-runtimeto upstream them in bite-sized pieces. Concurrently, we are working to re-enableamdkfdwithin FreeBSD's nativeamdgpudriver port, updating it to match Linux kernel version 6.18.4. We are currently testing this on a Framework Desktop powered by a Strix Halo APU, where hardware support was stabilized in the 6.18.x kernel series.The patchset is still a work in progress, and I am still parsing through it to extract clean commits. But I wanted to reach out to the systems architects here to ask; What is the preferred architectural pattern for introducing a new operating system target to
rocr-runtime?I have noticed the existing
os_tenums and scattered platform checks inCMakeLists.txt. When introducing large platform specific overrides (like OS memory mapping, and threading wrappers), is it better to encapsulate these into entirely separate files (i.e a separate os_freebsd.cpp), or extending existing files via preprocessor macros.All reactions