-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
rocmPackages_6: init at 6.0.2(?) #289187
rocmPackages_6: init at 6.0.2(?) #289187
Conversation
fa4276b
to
be6e5e7
Compare
Hey, @mschwaig what are you testing out? My rocm6 branch seems to be building rocmModules_6.rocm-all and the project I'm working on seems to work find against it. Maybe you have something you'd like to test against it? |
I can test |
Yeah, why not. It'll be one of my first PRs so will need some love I'm sure. |
I did some testing now, but I did not get to what I actually wanted to do yet. By running I have not gotten to testing The command I ran is
The I would like to have one of our branches in a state where everything builds, but it's a pain to test this since I only have 64 GB of RAM on my primary machine right now. I think to address this on your branch it would make sense to rebase your work onto a some state of master where all the dependencies of ROCm properly build. Alternatively waiting for a version of master where that build failure is resolved and removing the Maybe it makes sense to move this out of the draft stage or do whatever else is required so that hydra can try building it. |
I managed to get a complete run of
for this branch now. Result of 7 packages marked as broken and skipped:
7 packages failed to build:
87 packages built:
EDIT: as far as I can tell the build for those failing packages did not even run because of |
Happy, to do a rebase. I can possibly find the last version that libjpeg-turbo built on, but not sure if there is any reasonable way to find a version that builds all dependents?
By everything, do you mean everything everything? Or all dependents? I have ~190GBs locally, so could possibly leave something running overnight.
Sounds like I should move this out of draft after I find a rebase target? Sounds good to me. |
You can just use the commit that I started my branch on for the rebase. That's
Yes it you think that everything that's supposed to work is working you can move it out of draft, which signals to people that it's ready to take a look. I don't actually know if this will trigger some infra to actually build it, or if we have to @ a bot for that. I have never worked on a PR that requires so much compute to build before, so I never had to rely on having build results visible online. |
Since so far you did not rebase this branch to get rid of that issue with The only changes that I did not take so far where these (diff from my perspective). diff --git a/pkgs/development/rocm-modules/6/rocm-runtime/default.nix b/pkgs/development/rocm-modules/6/rocm-runtime/default.nix
index 8c3d0cdc976d..149c9b23c933 100644
--- a/pkgs/development/rocm-modules/6/rocm-runtime/default.nix
+++ b/pkgs/development/rocm-modules/6/rocm-runtime/default.nix
@@ -16,7 +16,7 @@
stdenv.mkDerivation (finalAttrs: {
pname = "rocm-runtime";
- version = "6.0.2";
+ version = "6.0.0";
src = fetchFromGitHub {
owner = "ROCm";
@@ -45,6 +45,7 @@ stdenv.mkDerivation (finalAttrs: {
postPatch = ''
patchShebangs image/blit_src/create_hsaco_ascii_file.sh
patchShebangs core/runtime/trap_handler/create_trap_handler_header.sh
+ patchShebangs image/blit_src/create_hsaco_ascii_file.sh
patchShebangs core/runtime/blit_shaders/create_blit_shader_header.sh
substituteInPlace CMakeLists.txt \
diff --git a/pkgs/development/rocm-modules/6/rocm-thunk/default.nix b/pkgs/development/rocm-modules/6/rocm-thunk/default.nix
index 99a1d3c542d1..9e88f1c7d9f1 100644
--- a/pkgs/development/rocm-modules/6/rocm-thunk/default.nix
+++ b/pkgs/development/rocm-modules/6/rocm-thunk/default.nix
@@ -10,7 +10,7 @@
stdenv.mkDerivation (finalAttrs: {
pname = "rocm-thunk";
- version = "6.0.2";
+ version = "6.0.0";
src = fetchFromGitHub {
owner = "ROCm"; I was under the impression that there would be more differences between our branches. Last time I looked I thought there were a bunch of different hashes. I did not see a lot of that now, so there's not really a lot that I would ask in a review in terms of code, besides asking who's version numbers in the above diff are right and why you did 23a4e3b and de5d15d, since those packages built for me without the changes. |
I rented a VM again to build my PR overnight with If everything builds like that I will look at building against master, or move my PR out of draft (if that's OK with you). |
After the nightly build for #287846 there were still a few broken packages. I fixed some of those build failures, but |
Thanks for working on that. I've been away for a bit. Going to check it out a bit this weekend. |
Took a look through hydra, it looks like 12f69cd might have been the last successful build of rocmPackages_5 ? |
Ran updateScript and a few minor hash fixes, and version renames.
New files need to have patched shebangs. Output structure of rocm-runtime changed, removing fixup script.
…get upgraded to a 7+ since that should go in rocmModules_7
Upgraded patches, and added missing packages. Removed gcc12Stdenv usage for some of the packages, moved what I could to rocmClangStdenv and the rest to default stdenv. This resolved a few errors with linking the test cases.
There have not been updates avaialble for this package for some time. I'm assuming it makes sense to drop it.
The build still fails, but it fails later.
We hit relocation R_X86_64_PC32 out of range errors for release builds that include all available targets. See: ROCm/composable_kernel#789
Update sources for llvm, clang-ocl, MIOpen and hsa-amd-aqlprofile-bin.
…ution. The update script seems to have updated these packages poorly, manually fixing the hashes.
I have not looked into the specific commit that you mentioned, but I have found the files that were missing from the Since my PR has some of your changes I wanted to ask if it would be OK for you if I merge some of your changes that way? |
Of course merge away |
Hey, I'm currently trying to use this with Ollama, rocblas seems to just get stuck forever on I'm also running a |
Description of changes
#197885
Upgrading to ROCm 6.0.2
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.