Update toolchain and some dependencies to be in line with Rust-GPU version 0.9 #153
Conversation
…t nightly. Had to update the vek, sysinfo, and rayon crates, since they wer pulling in code from dependencies that has long since been broken. rustc codegen nvvm is still broken, seems to have a number of issues. Once I got Optix installed and setup, I started having trouble with llvm. The build file seems to need llvm-config, which does not ship with precompiled binaries for llvm. I compiled llvm from source, but am still unable to get the build file to find that correctly. There are also a number of regular errors which will need to resolved slowly.
… versions. Going to tackle any breaking changes next
…red by the structs they were contained in. This has been resolved
…thod, which was previously throwing an error
… throwing an error before
ForwardPort
… to replace with the standardized version from the std library, but the dependency does not seem to be in use anyway
…f rust-gpu. Also updated crate dependencies to be compatible with this release. Using this toolchain means we're stuck to an older version of bindgen. In newer versions of llvm, characters for identifiers of files are emitted that bindgen says are invalid. This was fixed in bindgen 0.62, but since we're on 0.58, we don't have that bug fix and need to use llvm version 15 or older
… been removed in all these places
…g object directly
…o implement other traits inside rand. Tested, and everything compiles
|
This is probably redundant, similar changes made here: #152 |
…f rust-gpu. Also updated crate dependencies to be compatible with this release. Using this toolchain means we're stuck to an older version of bindgen. In newer versions of llvm, characters for identifiers of files are emitted that bindgen says are invalid. This was fixed in bindgen 0.62, but since we're on 0.58, we don't have that bug fix and need to use llvm version 15 or older
… been removed in all these places
…miedium/Rust-CUDA into UpdateToolChainAndFixGpuRand
Schmiedium
changed the title
|
rebased on top of main after #152 was merged, renamed the pull request, minor formatting fixes |
|
@Schmiedium are you going to try to the full forward port? If so, ping me when you are ready for me to take a look. I can also take a crack at it as I did similar work in the past if you prefer. |
|
I would like to try! I spent a bunch of time making an attempt for a newer version of the tool chain, but that ended being incompatible with this version, so I kinda scrapped that. I'm pretty confident I can do the forward port if we're good on the tool chain version. Definitely would like to get eyes on it if you wouldn't mind, I'll ping you when I can get the codegen to compile, and then take it from there. I can open an issue or draft pull request to track progress on that too, or even just use this one. |
|
Hey @Schmiedium, I have a branch on my fork that's updated to nightly-2025-03-02. The nvvm backend compiles, and it can compile |
|
Oh nice! That's awesome, I'll definitely take a look. Yeah, if you get everything working before I do, that'd be great. I've never worked on something like this before, so I don't want to hold up progress if you can do it faster. I've been looking at the rust-gpu codegen and the llvm codegen for reference here, but looking at yours would be really helpful too |
|
@Schmiedium sounds like this should be abandoned then? |
|
@jorge-ortega awesome! Let me know if I can help. Feel free to ping me directly when you are ready to put up a PR |
|
@LegNeato I think so, if Jorge is willing to do the port and is further along than me, then by all means. @jorge-ortega same for me, if I can help in any way, then please let me know! |
|
My branch can now compile external deps on the cuda target, but fails to build cuda_std, and probably others but that's as far as I got. I believe they are mostly related to the updated crates (bitflags, etc.). @Schmiedium , some of your commits may have already addressed those issues. Do you think you can try to merge/rebase my branch into your fork and see if you can still make progress? @LegNeato I'm thinking that I can open a PR just for the codegen/toolchain changes, and schmiedium can fix the remaining crates with this PR. That should make things a little easier to review, and preserve the work done between the two of us. |
|
@jorge-ortega I would be happy to! I'll rebase my fork on top of your branch and see what I can do |
|
Have you guys been able to build optix? @jorge-ortega I rebased on your branch but still running into optix issues. I created this discord server so we can collaborate faster https://discord.gg/Fkm5w2uJ |
|
Hi @trigpolynom. I haven't focused on optix yet. I just rebased the nightly branch on my fork to open PR #155. Apologies ahead of time if that might cause further issues. |
|
I'm going to close this pr, I think it's been overtaken by a bunch of other work and is no longer relevant |
I changed the toolchain to target the same rust version as the 0.9 release of Rust-GPU. from what I could see, this was the most recent release, so hopefully the two project will be in relative sync with this. There was concern that the newest toolchain would not be feasible to update too.
Along with the new toolchain and as part of the forward port, gpu_rand had some breaking changes that needed to be addressed. Mostly minor fixes, some trait methods changed and Seed512 needed to implement AsRef<[u8]>. Error is also no longer a part of rand_core.
optix_wrapper.rs is auto_generated from bindgen, and had to be regenerated when switching bindgen versions.