Add function get_device

[oschulz]

Closes #268

[vchuravy]

bors try

[bors]

try

Build failed:

• CI-julia-nightly (nightly, ubuntu-latest, x64)

[vchuravy]

@jpsamaroo can you unbork AMDGPU on nightly?

[oschulz]

In the examples, we could now simplify code like

    if isa(a, Array)
        kernel! = naive_transpose_kernel!(CPU(),4)
    else
        kernel! = naive_transpose_kernel!(CUDADevice(),256)
    end

to

    device = KernelAbstractions.get_device(A)
    n = isa(a, AbstractGPUArray) ? 256 : 4
    kernel! = naive_transpose_kernel!(device,n)

but it would require a dependency (at least for the example) on GPUArrays.jl.

I could also add a function isgpuarray (or similar), then we could do

    device = KernelAbstractions.get_device(A)
    n = KernelAbstractions.isgpuarray(A) ? 256 : 4
    kernel! = naive_transpose_kernel!(device,n)

without additional dependencies. What do you think?

[vchuravy]

Hm we could also add a default static launch size, but it is just an example. What I would do there is not check for GPU-ness, but check for Array

[oschulz]

but check for Array

But what's if the user passes a SubArray or so?

Hm we could also add a default static launch size

My thinking was that the author of naive_transpose!(a, b) can judge best how much parallelism would make sense, given the input size. Now they just need to know what's possible on the hardware side - do we have a cross-vendor API function to query device capabilities?

[oschulz]

But as for the example - silly me, we can just do

    device = KernelAbstractions.get_device(A)
    n = device isa GPU ? 256 : 4
    kernel! = naive_transpose_kernel!(device, n)

Very literate, I think. :-)

[oschulz]

I changed the examples accordingly.

[oschulz]

Looks like bors is still running. :-)

[vchuravy]

bors try

[bors]

try

Build failed:

• buildkite/kernelabstractions-dot-jl/rocm-julia-1-dot-6

[oschulz]

@vchuravy , does this design look better to you now?

[vchuravy]

I guess so, I am not a fan that this requires us pulling LinearAlgebra and SparseArrays in even though these are currently stdlibs. I would rather have the question of "what is your storage array" be solved somewhere like Adapt.jl

[vchuravy]

bors try

[bors]

try

Build failed:

• CI-julia-nightly (nightly, ubuntu-latest, x64)

[oschulz]

I would rather have the question of "what is your storage array" be solved somewhere like Adapt.jl

Yes, that would be nice - I've also been thinking that it would be nice if Adapt.jl would get a "read/inspect" functionality in addition to the "write/transform" functionality in the future. In the end, the designer of a data structure knows best what "underlying" data should mean (esp. if there are several arrays), so the clean way of doing a recursive "where is this stored?" would be to implement an "inspect" companion to adapt().

[oschulz]

Is bors hanging?

[vchuravy]

bors try

[bors]

try

Build failed:

• CI-julia-nightly (nightly, ubuntu-latest, x64)

[oschulz]

Is bors stalled again?

[vchuravy]

You can click on the red x next to they "Try #" https://github.com/JuliaGPU/KernelAbstractions.jl/runs/3927630339

[jpsamaroo]

ROCm CI got hung after I updated the local buildkite repo; I've restarted the runners, which are now processing jobs.

[oschulz]

Thanks!

[oschulz]

I think the remaining test failures are unrelated to this PR (correct?).

[oschulz]

I saw JuliaGPU/AMDGPU.jl#187 got merged with a new AMDGPU.jl release. Should we try bors again?

[oschulz]

@jpsamaroo , could you kick bors again, with the new AMD fixes?

[jpsamaroo]

@oschulz you would need to rebase on #288, although that PR isn't yet CI-green.

[oschulz]

rebase on #288, although that PR isn't yet CI-green.

Ah Ok - maybe easiest to just wait until #288 is in, then?

[oschulz]

I saw you made some changes @vchuravy , do I need to do anything in addition?

(Am I correct that the current test failures are unrelated to this PR?)

[vchuravy]

The ROCM failure looks related, only Julia nightly is currently expected to fail.

[vchuravy]

Thank you Oliver!

[oschulz]

Thank you Valentin!