You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Native GPU support.
* Add some devdoc
Co-Authored-By: Mark Kittisopikul <[email protected]>
* Simplify `update_eltype` and add more test
This should omit the `isempty` check if inference give good result.
fix test on 1.6, `range(2, 19.0, 101)` was introduced in 1.7
* Fully drop the old indexing overload for `WeightedIndex`.
and remove unneeded `@propagate_inbounds`.
* Reenable non-generated `interp_getindex`.
And fix the inference problem.
Co-authored-by: Mark Kittisopikul <[email protected]>
Copy file name to clipboardExpand all lines: docs/src/devdocs.md
+33-5Lines changed: 33 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,6 +55,8 @@ concrete subtypes:
55
55
General `AbstractArray`s may be indexed with `WeightedIndex` indices,
56
56
and the result produces the interpolated value. In other words, the end result
57
57
is just `itp.coefs[wis...]`, where `wis` is a tuple of `WeightedIndex` indices.
58
+
To make sure this overloading is effective, we wrap the `coefs` with `InterpGetindex`,
59
+
i.e. `InterpGetindex(itp.coefs)[wis...]`
58
60
59
61
Derivatives along a particular axis can be computed just by substituting a component of `wis` for one that has been designed to compute derivatives rather than values.
In this case you can see that `wis` is a 3-tuple-of-3-tuples. `A[wis[i]...]` can be used to compute the `i`th component of the gradient.
@@ -168,3 +170,29 @@ The code to do this replacement is a bit complicated due to the need to support
168
170
It makes good use of *tuple* manipulations, sometimes called "lispy tuple programming."
169
171
You can search Julia's discourse forum for more tips about how to program this way.
170
172
It could alternatively be done using generated functions, but this would increase compile time considerably and can lead to world-age problems.
173
+
174
+
### GPU Support
175
+
At present, `Interpolations.jl` supports interpolant usage on GPU via broadcasting.
176
+
177
+
A basic work flow looks like:
178
+
```julia
179
+
julia>using Interpolations, Adapt, CUDA # Or any other GPU package
180
+
181
+
julia > itp = Interpolations.interpolate([1, 2, 3], (BSpline(Linear()))); # construct the interpolant object on CPU
182
+
183
+
julia> cuitp =adapt(CuArray{Float32}, itp); # adapt it to GPU memory
184
+
185
+
julia >cuitp.(1:0.5:2) # call interpolant object via broadcast
186
+
187
+
julia>gradient.(Ref(cuitp), 1:0.5:2)
188
+
```
189
+
190
+
To achieve this, an `ITP <: AbstractInterpolation` should define it's own `Adapt.adapt_structure(to, itp::ITP)`, which constructs a new `ITP` with the adapted
191
+
fields (`adapt(to, itp.fieldname)`) of `itp`. The field adaption could be skipped
192
+
if we know that it has been GPU-compatable, e.g. a `isbit` range.
193
+
194
+
!!! note
195
+
Some adaptors may change the storage type. Please ensure that the adapted `itp`
196
+
has the correct element type via the method `eltype`.
197
+
198
+
Also, all GPU-compatable `AbstractInterpolation`s should define their own `Interpolations.root_storage_type`. This function allows us to modify the broadcast mechanism by overloading the default `BroadcastStyle`. See [Customizing broadcasting](https://docs.julialang.org/en/v1/manual/interfaces/#man-interfaces-broadcasting) for more details.
0 commit comments