-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
miopen: init at 2.18.0-5.3.3 #202476
miopen: init at 2.18.0-5.3.3 #202476
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Builds fine for me. Maybe we should add miopen-hip
and miopen-opencl
to nixpkgs?
Honestly it seems a little redundant to me, but then I think we're going to have to do something similar for pytorch anyway, so alright. |
On second thought, miopen should be the base and just toggle |
] ++ lib.optionals buildDocs [ | ||
latex | ||
doxygen | ||
sphinx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use SphinxHook, build the documentation unconditionally and enable the doc and/or man outputs. They can be installed per user-choice through the documentation module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many of the other ROCm derivations I've made do the same, why use SphinxHook here?
The others also don't build the documentation unconditionally, so again, why here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I first spotted it here. It's a recommendation to simplify things, not a precondition to get things merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not having this built on hydra is rough and makes it obvious why parts of the build were made conditional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay makes sense.
It might be a little bit before I commit the new changes since I gotta rebuild everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few other derivations that build documentation so it might be easier to merge this as-is and then I'll submit a rocm-related
PR concerning sphinxHook
.
The directories are all over the place for ROCm, so I'm not entirely sure one solution will work for all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, need to fix the docs
review before merge. One moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some testing, simplifying this with sphinxHook
isn't a good option.
The documentation seems to depend on certain variables from cmake.
Here's what I have done: Madouura@f4ae10e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also lose the ability to reasonably generate the pdf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarification: The documentation does build, but will silently error in the actual documents.
You'll get missing parts and messed up in-lines.
, zlib ? null | ||
, fetchurl ? null | ||
, buildDocs ? false | ||
, buildTests ? false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the tests optional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are not needed for use as a dependency or for end-user functionality.
They can also be costly to build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are probably important to check whether the packaging works out alright. Not sure what "can also be costly" means vs. being actually costly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most tests don't run within the nix sandbox, also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also the reason why #200757 exists.
Tests will need to be run in an impure fashion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should not be ? null
heres regardless if the tests are run or not, if they are currently broken or not.
Description of changes
Tracking: #197885
I wanted to get either a way to generate KDBs or more of them added to https://repo.radeon.com/rocm/miopen-kernel/rel-5.0/, but I don't think that's gonna happen for a while. So, doing the PR now.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes