What are good guidelines to suggest "this will scream on a gpu"

[jeffrey.sarnoff]

This {approach, design space, domain, problem (general), algorithm (specific), ...} will scream on a gpu and is ready/easy to get make ready/ .. hard to develop.

[Valentin Churavy]

Are you looking for guidelines to suggest features or do you want to collect ideas?

The two most exciting things in Julia space (w.r.t. GPU) for me are currently Simons work on GLVisualize and my own feeble attempts to automatically compile Julia code for the GPU, sadly the latter one is currently dormant because I am waiting on 0.4 to be branch =and the codegen changes to be merged. 

-V

[jeffrey.sarnoff]

I want to collect ideas, have a place for people to look that includes what is available in Julia today and inspires but does not try to direct what becomes available.

[Chiyuan Zhang]

+1 for the feature of being able to write GPU kernels with Julia directly!

- chiyuan

On Sunday, August 16, 2015 at 8:19:25 PM UTC-4, Valentin Churavy wrote:

[Tim Holy]

I agree it would be awesome to be able to write GPU kernels in Julia.

But Valentin, I'm curious: how much would the code basically look the same as
what you'd write in C? The example at https://github.com/maleadt/CUDA.jl is so
short, I have a hard time guessing whether it's basically C-with-a-Julia-
function-declaration, or whether there are real advantages compared to writing
in C and compiling to a PTX file. Certainly the usage of blockId and threadId
means "you have to know something about GPU programming" (it's a little hard
to imagine it any other way, of course).

Despite my question, I agree this is one of the most exciting frontiers. Even
if it has to look exactly like the C today, I could imagine that situation
might change rapidly as more people started doing this and the @target macro
grew more sophisticated.

Best,
--Tim

[Simon Danisch]

@tim holy

Just consider macros, @generated etc. They should all mostly work, as long as one sticks to a more C-like subset of Julia.

Also, multiple dispatch and varargs would be gold in my opinion.

Right now I need to write functions like this:

vec2 linear_index(ivec2 dims, int index)

{

    ivec2 index2D = ind2sub(dims, index);

    return vec2(index2D) / vec2(dims);

}

vec2 linear_index(ivec2 dims, int index, vec2 offset)

{

    vec2 index2D = vec2(ind2sub(dims, index))+offset;

    return index2D / vec2(dims);

}

vec3 linear_index(ivec3 dims, int index)

{

    ivec3 index3D = ind2sub(dims, index);

    return vec3(index3D) / vec3(dims);

}

Which could be one generic function in Julia.

@generated, or some similar more approved solution, would be very powerful on the GPU for JIT compilation of specialized kernels.

[Valentin Churavy]

@Tim, I agree that just using a C-style Julia for writing kernels wouldn't be

as exciting (besides solving a part of the two-language problem). I think that

there is a huge design space to explore how to bring the power of Julia to 

GPGPU programming and especially heterogeneous computing.

I hope that SPIR-V support is landing soon(tm) in llvm and we only need to

target one environment. 

As far as I know Simon has been thinking about recompiling parts of a 

callgraph created with something along the lines of Reactive and executing

on an accelerator. 

In general my goal would be to first get a subset of Julia working as a 

kernel language, then add something along the line of OpenACC or

OpenMP offload. 

Either way it is going to be quite a lot of work and it also depends on 

work yet to be in llvm. 

[René Donner]

Although I have never used it in production (yet), I am quite impressed by Halide (halide-lang.org), especially by its seperation of logic and compute schedule (storage layout / compute & memory access patterns). It also allows to use the same source code to generate optimized GPU and/or multi-code CPU code!

Tim, you have a repo called Halide.jl - were you trying to wrap it at some point?

It would be absolutely amazing to be able to write Halide code "as Julia" code.

I started with that a long time ago (bit didn't follow through), basically just trying to map the Halide types and functions to Julia. For code generation I was simply planning to go the convert-AST-to-C-and-invoke-halide route, as I believe it is much easier at first.

What do you think?

Am 18.08.2015 um 19:10 schrieb Tim Holy <tim....@gmail.com>:

> I agree it would be awesome to be able to write GPU kernels in Julia.
>
> But Valentin, I'm curious: how much would the code basically look the same as

> what you'd write in C? The example athttps://github.com/maleadt/CUDA.jl is so

> --
> You received this message because you are subscribed to the Google Groups "julia-gpu" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to julia-gpu+...@googlegroups.com.
> To post to this group, send email to juli...@googlegroups.com.
> To view this discussion on the web visithttps://groups.google.com/d/msgid/julia-gpu/1620610.XgeQqIoO7L%40diva.
> For more options, visithttps://groups.google.com/d/optout.

[Valentin Churavy]

So Jake once tested generating OpenCL C from Julia (https://github.com/JuliaGPU/OpenCL.jl/tree/clcompiler2) this was over two years ago.

I personally think going from Julia (AST) -> C -> GPU Binary is much harder than going from Julia -> LLVM IR -> GPU Binary. For the latter codegen path most of it is already written. Once you generate the correct annotated LLVM-IR generating the GPU binary is simple, but so far this had one major downside SPIR and to some extend NVPTX where evolving along side llvm, so to produce SPIR in a specific version of the standard you had to also have a matching llvm. I hope that this will be solved or minimized with SPIR-V, which has no dependency on the LLVM-IR. So in then end our codegen path would be Julia -> LLVMI-IR -> SPIR-V -> GPU-Binary and the only thing we really need is a mechanism in base to switch codegen contexts from native to spir-v and a mechanism to give the compiler a bit more information then we currently are doing.

[Jeffrey Sarnoff]

There is important plumbing that does not exist?

To view this discussion on the web visit https://groups.google.com/d/msgid/julia-gpu/25a9d5f5-efa9-477a-94c0-efd7452ac869%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tim Holy]

That Halide repository is minimalistic but works, or it did the last time I
checked. That said, my whole plan was to use it for benchmarking against my
KernelTools.jl repository, which basically brings Halide-style design to pure
Julia code. (See the `@tile` macro in particular.) Other than GPU access, I
don't think Halide offers anything that we can't provide in pure Julia, as long
as someone is willing to help finish it off!

The main thing that I think KernelTools needs to do is change the @tile macro
so that it creates callable functions instead of blocks within functions. Then
we can set up a threading model. It literally might only be a few days of work
to get there, but I have too many projects going on at once to think clearly
about it right now.

--Tim

[Tim Holy]

This sounds really promising, and would be quite amazing.

I know that maleadt's work is based on CUDA, but for "non-experimental" uses
CUDArt now has some advantages. When the time comes, if you want to integrate
the two I am happy to do what I can to help out.

--Tim

> > Groups "julia-gpu" group.
> >
> > > To unsubscribe from this group and stop receiving emails from it, send
> >

> > an email to julia-gpu+...@googlegroups.com <javascript:>.

> >
> > > To post to this group, send email to juli...@googlegroups.com
> >

> > <javascript:>.

[Valentin Churavy]

KernelTools looks promising :)

w.r.t to Cuda.jl and CudaART.jl I actually started working on collapsing

the work maleadt so that we would have CUDANative. But Julia v0.4 

got in my way ;) 

I think the a sensible roadmap would be to get the llvmcall [1] and 

address space preserving bitcasts [2] into 0.5 and aiming for multiple

backend support in v0.6/0.7 

My hope would be that beside those changes and some way to hook

into codegen we could do most of the work in packages. Jake hinted 

at the creation of a julia codegen library that one could use for things 

like this or having a better llvm interface from Julia [3] 

[1] https://github.com/JuliaLang/julia/pull/11604

[2] https://github.com/JuliaLang/julia/pull/9423

[3] https://github.com/JuliaGPU/OpenCL.jl/issues/29

[Valentin Churavy]

So I started working on compiling to GPU again after v0.4 was branched. My PR for llvmcall is rebased onto 0.5-dev and hopefully I will get around to rebasing the preserving bitcasts.

The big question is how to sanely support multiple backends, preferably outside of julia base. I would like to have minimal support for swithcing backends in julia and

 then implement those backends outside of julia base, but that will require a lot more work. So ideas and help are welcome.