-
Notifications
You must be signed in to change notification settings - Fork 207
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
Implement a new ReactantState architecture #4071
Conversation
src/Architectures.jl
Outdated
##### | ||
##### These methods are extended in DistributedComputations.jl | ||
##### | ||
|
||
device(::CPU) = KernelAbstractions.CPU() | ||
device(::GPU) = CUDA.CUDABackend(; always_inline=true) | ||
# While there is no Reactant backend this worls | ||
device(::ReactantState) = CUDA.CUDABackend(; always_inline=true) |
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.
Does it make sense to let the backend be a property of ReactantState?
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.
Currently this is used to say we are importing CUDA kernel source code to reactant, which is the current correct default (and should be decided in the KA reactant backend when ready).
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.
ok I see, I had a misconception about the meaning of "backend" and "device"
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.
I guess a comment would be appropriate here to describe what is happening
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.
Added comment
automatic: | ||
- exit_status: 1 | ||
limit: 1 | ||
depends_on: "init_cpu" |
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.
Does it make sense to have CPU tests if the backend is hardcoded for GPU? I may be missing something…
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 is not hardcoded for GPU, counterintuitively.
Reactant is taking in the CUDA kernels but then deciding to execute it on whatever the reactant default backend is (which could be CPU or TPU — we just landed the GPU kernel to CPU kernel support last night. TPU in progress).
we could introduce this change as part of this PR: #3475 (comment)_ |
We are also missing a method for Oceananigans.jl/src/Architectures.jl Line 118 in 06a7c1b
necessary for split explicit free surface. Also over here we can just use the KA equivalent instead of manually converting |
for reference |
Can we improve that interface? It's pretty unclear what exactly we are "converting" to. Shoiuld it be |
@jm-c can you please approve this PR so that it can be merged? |
I would wait a second, there are still some items to be solved |
src/Architectures.jl
Outdated
##### | ||
##### These methods are extended in DistributedComputations.jl | ||
##### | ||
|
||
device(::CPU) = KernelAbstractions.CPU() | ||
device(::GPU) = CUDA.CUDABackend(; always_inline=true) | ||
# While there is no Reactant backend this worls |
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.
# While there is no Reactant backend this worls | |
# Temporary fix before we develop a Reactant backend |
With
|
Ok so this is a bug we get on a machine with no GPU? We can set up a test on the GitHub actions pipeline to catch? |
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.
I know this was already merged, but should these commented lines be 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.
I can't see the lines you're referring to
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.
Probably
# include("Utils.jl") | |
# include("BoundaryConditions.jl") | |
# include("Fields.jl") | |
# include("MultiRegion.jl") | |
# include("Solvers.jl") | |
using .Architectures | |
# using .Utils | |
# using .BoundaryConditions | |
# using .Fields | |
# using .MultiRegion | |
# using .Solvers |
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 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.
Yeah, sorry, these were indeed the lines. I accidentally tagged the wrong thing.
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.
Yeah so these are "additional modules that may need to be extended", helpful for people working on compat who aren't intimately familiar with the internal structure of Oceananigans. I can add that note in a subsequent PR
No this doesn't have anything to do with CPU. The issue is that
How did you do your package setup? Maybe we should do a release to fix cc @gbaraldi |
I'm just becoming aware of this PR (after it was merged) and I'm wondering if the top comment can be updated with some context. I guess A general comment is that I think we should avoid PRs with no context/explanation except for very small self-explanatory cases. (Fixing a typo for example) |
Oops, I didn't mean to delete your comment @giordano ! |
I get something similar Reactant Super Simple Simulation Tests: Error During Test at /Users/gregorywagner/Projects/dev/Oceananigans.jl/test/test_reactant.jl:16
Got exception outside of a @test
ArgumentError: No available targets are compatible with triple "nvptx64-nvidia-cuda"
Stacktrace:
[1] LLVM.Target(; name::Nothing, triple::String)
@ LLVM ~/.julia/packages/LLVM/b3kFs/src/target.jl:33
[2] Target
@ ~/.julia/packages/LLVM/b3kFs/src/target.jl:23 [inlined]
[3] llvm_machine(target::GPUCompiler.PTXCompilerTarget)
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/ptx.jl:49
[4] macro expansion
@ ~/.julia/packages/GPUCompiler/2CW9L/src/ptx.jl:140 [inlined]
[5] macro expansion
@ ~/.julia/packages/LLVM/b3kFs/src/base.jl:97 [inlined]
[6] finish_module!(job::GPUCompiler.CompilerJob{GPUCompiler.PTXCompilerTarget}, mod::LLVM.Module, entry::LLVM.Function)
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/ptx.jl:137
[7] finish_module!(job::GPUCompiler.CompilerJob{GPUCompiler.PTXCompilerTarget, CUDA.CUDACompilerParams}, mod::LLVM.Module, entry::LLVM.Function)
@ CUDA ~/.julia/packages/CUDA/2kjXI/src/compiler/compilation.jl:58
[8] macro expansion
@ ~/.julia/packages/GPUCompiler/2CW9L/src/driver.jl:183 [inlined]
[9] emit_llvm(job::GPUCompiler.CompilerJob; toplevel::Bool, libraries::Bool, optimize::Bool, cleanup::Bool, validate::Bool, only_entry::Bool)
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/utils.jl:108
[10] emit_llvm
@ ~/.julia/packages/GPUCompiler/2CW9L/src/utils.jl:106 [inlined]
[11] codegen(output::Symbol, job::GPUCompiler.CompilerJob; toplevel::Bool, libraries::Bool, optimize::Bool, cleanup::Bool, validate::Bool, strip::Bool, only_entry::Bool, parent_job::Nothing)
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/driver.jl:100
[12] compile(target::Symbol, job::GPUCompiler.CompilerJob; kwargs::@Kwargs{optimize::Bool, cleanup::Bool, validate::Bool, libraries::Bool})
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/driver.jl:79
[13] compile
@ ~/.julia/packages/GPUCompiler/2CW9L/src/driver.jl:74 [inlined]
[14] (::ReactantCUDAExt.var"#10#13"{GPUCompiler.CompilerJob{GPUCompiler.PTXCompilerTarget, CUDA.CUDACompilerParams}})(ctx::LLVM.Context)
@ ReactantCUDAExt ~/.julia/packages/Reactant/7y9bj/ext/ReactantCUDAExt.jl:420
[15] JuliaContext(f::ReactantCUDAExt.var"#10#13"{GPUCompiler.CompilerJob{GPUCompiler.PTXCompilerTarget, CUDA.CUDACompilerParams}}; kwargs::@Kwargs{})
@ GPUCompiler ~/.julia/packages/GPUCompiler/2CW9L/src/driver.jl:34 |
@glwagner your issue is distinct and a Macos-specific issue resolved in JuliaGPU/GPUCompiler.jl#660 (released an hour ago). It should work fine on linux (or mac once gpucompiler is updated across the ecosystem) |
excellent news |
This allows us to use Reactant's traced arrays with Oceananigans, which permits optimization via XLA.