rocmPackages: 6.3.3 -> 6.4.3#427944
Conversation
e8872b0 to
f034276
Compare
This comment was marked as outdated.
This comment was marked as outdated.
ed91505 to
8d8c252
Compare
8d8c252 to
11a7af6
Compare
29e7d0c to
2758d52
Compare
This comment was marked as outdated.
This comment was marked as outdated.
8089e29 to
87e341b
Compare
6715162 to
8b7c3c1
Compare
8b7c3c1 to
251034d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
@LunNova What's the remaining works need on this Merge request ? New version is available: https://github.com/ROCm/ROCm/releases/tag/rocm-6.4.3 |
|
The PR might be fine in its current state, I haven't had time to do proper testing since applying @GZGavinZhao's newest iteration of the isa compat patches. Have been helping with #431973 this week. |
Okay thx for you reply ^^ nice works ! |
This comment was marked as outdated.
This comment was marked as outdated.
|
I'm packaging 6.4.3 for Solus and I've found it is so similar to 6.4.2 that updating should be as simple as updating the source version and hash, so I'm not too worried about this PR taking a bit more time to merge. |
There was a problem hiding this comment.
AMD doesn't update everything with every version, and the versions listed there are not the actual module versions but the associated rocm versiom. You can see the real ones here, e.g. rocFFT moved from 1.0.31 to 1.0.32 between rocm 6.3 and 6.4, but stayed at 1.0.32 from rocm 6.4.2 to 6.4.3.
Not sure whether that's actually the best way to go about things, while it unifies the absolute mess that those individual module versions are it also (corrects me if I'm wrong) changes nar hashes without any good reason, also, it differs from upstream.
There was a problem hiding this comment.
Yeah it's a bit awkward that this wastes store space for the source archives. no it doesn't, FODs and name is source.
AMD's been publishing the entire package set by ROCm version for a while now, many packages within it don't even have their own versioning scheme.
Most of the rebuilding in rocmPackages can't be avoided by using a separate version for individual packages because the version number set in rocm-core and clr gets bumped and everything has that as an input.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
I'd like to avoid this massive reindent
There was a problem hiding this comment.
Shouldn’t need to inherit it if it’s in the scope. (Applies to a bunch of stuff in this file.)
There was a problem hiding this comment.
so this actually changes the stdenv because this is inheriting the original normal stdenv from pkgs from outside the package set. I need to do some renaming.
There was a problem hiding this comment.
renamed but it's still not very clear.
There was a problem hiding this comment.
It was an error for us to build 1012 by default in previous versions, our ISA compat patches allow 1010 to load for 1012 so this just wasted resources.
gfx1151 support in torch was fixed by the ROCm 6.4 bump
… supported targets are set Allows building torchWithRocm with clr's localGpuTargets set to gfx906 and other arches which composable_kernel does not support.
Will be required for CMake 4 bump which is hopefully happening in nixpkgs soon
There was a problem hiding this comment.
@emilazy sadly migraphx still needs a patch. going to try to upstream this.
|
llama-cpp failure to investigate: unsupported insn in a very recently added llama-cpp feature ggml-org/llama.cpp#15884 |
|

Fixes #412640
Fixes #418825
Fixes #434280
TODO
Test gfx11-generic handles strix halo if anyone is available to test with one of the new ryzen AI max boxesTest gfx9-generic handles early vegaThings done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.