Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Add gcc offloading to GPUs #366903

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

RFC: Add gcc offloading to GPUs #366903

wants to merge 4 commits into from

Conversation

viric
Copy link
Member

@viric viric commented Dec 20, 2024

Here is a dirty attempt to bring the "amdgcn-amdhsa" gcc offloading to nixpkgs. It's quite dirty but I wanted to have some 'working' base so we can translate to the structures that will handle this well. I was following the instructions in https://gcc.gnu.org/wiki/Offloading#Examples

Some of the difficulties are:

  • The offload compiler needs to use its self-built newlib, by putting newlib source into gcc source tree. That isn't nicely supported today; newlib is meant as a separate derivation.
  • I skipped the $lib output directory in gcc for simplicity.
  • The stages do not fit well enough to the two compilers required I think.
  • All is quite hardcoded to the single goal I had about gcc+amd.
  • I used noSysDirs=false becasue the gcc configure/makefiles build a FLAGS_FOR_TARGET ideal for building newlib, and overriding them from our makeFlags destroys that internal mechanism. I think we should have something like a libc name "newlib-in-gcc", additional to uclibc, etc. that made gcc build newlib all in one.

With this I could build a simple "openmp target" example code in the clang page about Offloading: https://clang.llvm.org/docs/OffloadingDesign.html#offloading-example

@Ericson2314 what is your opinion how can we make these things fit? Ideally we would want AMD/NVIDIA offload in gcc, and AMD/NVIDIA/Intel offload in clang.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added 6.topic: python 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 6.topic: haskell 6.topic: qt/kde 6.topic: kernel The Linux kernel 8.has: documentation This PR adds or changes documentation 8.has: changelog 8.has: module (update) This PR changes an existing module in `nixos/` 6.topic: emacs Text editor 6.topic: printing 6.topic: policy discussion 6.topic: ruby 6.topic: vim 6.topic: ocaml 6.topic: xfce The Xfce Desktop Environment 6.topic: fetch 6.topic: stdenv Standard environment 6.topic: nodejs 6.topic: hardware 6.topic: coq "A formal proof management system" 6.topic: nixos-container Imperative and declarative systemd-nspawn containers 6.topic: pantheon The Pantheon desktop environment 6.topic: TeX Issues regarding texlive and TeX in general 6.topic: lua 6.topic: testing Tooling for automated testing of packages and modules 6.topic: module system About "NixOS" module system internals 6.topic: systemd 6.topic: java Including JDK, tooling, other languages, other VMs 6.topic: vscode 6.topic: lib The Nixpkgs function library labels Dec 20, 2024
@viric viric marked this pull request as draft December 20, 2024 19:16
@viric viric added the 6.topic: cross-compilation Building packages on a different platform than they will be used on label Dec 20, 2024
@ofborg ofborg bot added 2.status: merge conflict This PR has merge conflicts with the target branch 8.has: package (new) This PR adds a new package and removed 2.status: merge conflict This PR has merge conflicts with the target branch labels Dec 21, 2024
@ofborg ofborg bot requested review from Synthetica9 and vcunat December 21, 2024 07:29
@wolfgangwalther
Copy link
Contributor

This should target master instead, right?

@viric
Copy link
Member Author

viric commented Dec 22, 2024

This should target master instead, right?

sure - I simply was doing the experiments on 24.11. This is not meant for merging yet. I only wanted to start the discussion on the bases of a dirty but working piece.

But it cannot target gfx1103 - that probably requires the
rocmPackages.llvm that is broken.
@viric viric changed the base branch from release-24.11 to master December 22, 2024 13:48
@ofborg ofborg bot added 2.status: merge conflict This PR has merge conflicts with the target branch and removed 2.status: merge conflict This PR has merge conflicts with the target branch labels Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: cross-compilation Building packages on a different platform than they will be used on 6.topic: lib The Nixpkgs function library 6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 11-100 10.rebuild-linux: 101-500
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants