-
Notifications
You must be signed in to change notification settings - Fork 195
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
Failed to compile PTX code ... uses too much parameter space #2700
Comments
Can you please report which version of Oceananigans are you using? |
Apologies, currently using |
Try |
Why are we overhauling the tracer tendency function? The problem appears to be in
It's just that we support user specification of velocity forcing functions that depend on any of the tracer fields. We could discontinue support for this though. As for passing T, S --- just to clarify, you mean to pass any tracers that are involved in the calculation of the buoyancy perturbation? (This could be buoyancy |
Okay, will try this |
Sorry I'm away from the computer with a GPU at the moment so can't check, but I think the reason I thought it would require changes to the tracer_tendency function is because it seems relatively straightforward to fix the issue with the velocity tendency functions (I hadn't realised you could have tracer dependent velocity forcing too so that may make it less straightforward), but then when I'd changed that a bit I realised it would be much harder to reduce the parameter size of the tracer tendency function if the tracers depend on lots of other tracers. And yeah sorry for the lack of clarity, I meant pass as required for buoyancy b/T/S |
We already do "unwrap" data from fields on the GPU: Oceananigans.jl/src/Fields/field.jl Line 368 in ea6826f
Okay, this makes sense. Solving the problem for Can you provide a minimum script that reproduces the error? I do think many tracers is an important use case so solving this could warrant reducing the kinds of forcing functions we support --- if that's necessary. I think there also may be solutions that don't change what we support while still solving this problem; eg we provide some features that extend model capabilities specifically for the case of large numbers of tracers. For example, we could avoid passing the tracers explicitly into the kernels. Instead, we can attach references only to the relevant / used fields directly in Or, we can explore JuliaGPU/CUDA.jl#267. |
Note that #1886 is related. |
Sorry for the slow replies, I am currently away. I will put together a MWE when I am back. More out of interest, is there a benefit to passing variables explicitly? |
Is this question about CUDA.jl behavior? I'm afraid I don't know, but this comment might help: It could be worth asking on #gpu slack, or on JuliaGPU/CUDA.jl#267. |
Dup of #1886 so lets discuss further there is need be |
Hi all,
I'm currently building a model with lots of forced tracers with @johnryantaylor and @syou83syou83 and have come across an issue that I'm struggling to find a way around related to GPU compilation.
I've spent a while looking through your previous similar issues (e.g. PR #746) and going through the error messages (below) the error message it gives and I'm fairly sure that its coming from the parameters size passed to the boundary tendency functions being too large.
I have looked through the source and while I think it would be possible to reduce the parameter size for the velocity tendencies by only passing them the T and S tracers as required (see the first, nonworking, step towards this here) I don't see how this problem can be solved in the
tracer_tendency
function since tracer forcing/boundaries may depend on any number of fields. I also realize that the choice to pass all the tracers may be required for something else I've missed.I can have a go at overhauling the
tracer_tendency
function etc. based on this suggestion and this but am not sure if its necessarily the best/nicest solution?Edit: Possibly could just remove a lot of the information from the fields using the
adapt_structure
method from PR #1057?Thanks!
(Apologies this error message is a bit mangled because I use
InteractiveErrors
)The text was updated successfully, but these errors were encountered: