It's a packed struct of 32b floats. I'm pretty sure it's the same format as Complex32, which would be convenient, but haven't verified.

#47 fixes this.

There's a .travis.yml but https://travis-ci.org/luqmana/rust-opencl doesn't appear to be active?

(Opening a bunch of issues today!)

This would require finding an OpenCL.lib from one of the various SDKs and linking to it. (Which doesn't currently happen, I believe.) That could be done with a build.rs script.

There are a lot of OpenCL extensions; it would be nifty to support them.
I would be particularly interested in the OpenGL (and DirectX) extensions, but I'm not sure how to implement those without adding a dependency on a Rust OpenGL implementation - which a problem, because different projects use implementations generated from different versions of the OpenGL spec. Maybe by exporting a macro?

(I've been hacking on an implementation of non-opengl extensions, will PR soon.)

Are you going to add examples as well ? They would be really helpful.

Hey! I'm trying to make use of rust-opencl with the beignet backend for my IvyBridge CPU/GPU. Unfortunately, it can't seem to find the backend, with hl.rs/get_platforms returning an empty vec.

I can build and run the beignet unit tests, and my /usr/local/lib looks like http://itdaniher.com/p?dpbq.

I'd love any pointers!

Ian

As far as I can tell, rust-opencl implements OpenCL 1.1. Would it be possible to support OpenCL 1.2 and 2.0? (And maybe 1.0, I suppose.) I don't believe there are backwards-incompatible changes; things are deprecated, but not removed.
It might be possible to set up version selection with a cargo build-time feature. The OpenCL headers are nicely annotated with version information.
It would be really cool to be able to select at runtime, based on the result of clGetPlatformInfo, at least for the high-level interface; I'm not sure what the best way to implement that would be, though.

The rustdocs don't seem to generate without adding these 2 lines to src/lib.rs:

![feature(libc)]

![feature(rustc_private)]

Are there any active users of the project interested in reducing the amount of opaque bits here? I count 50+ null pointers, a ton of functions that accept / return c_voids, and 5 calls to cast::transmute. If anyone's interested in throwing some cycles at it, I'll pitch in.

see http://doc.crates.io/crates-io.html

I'm trying to write some quick example code using rust + opencl, I'm pretty new to rust but when I run

let (device, ctx, queue) = opencl::util::create_compute_context_prefer(opencl::util::PreferedType::GPUPrefered).unwrap();
let (device1, ctx1, queue1) = opencl::util::create_compute_context_prefer(opencl::util::PreferedType::GPUPrefered).unwrap();

println!("{}", device.name()); //GT120
println!("{}", device1.name()); //GT120

Both of my device names are "Geforce GT120". In my PC however I have a GT120 in addition to a Radeon 7970.

Looking at the code I see that multiple devices are a TODO, what needs to be done to implement this?

Just got this when I compiled, might be a known problem but could be worth making an issue of it as it will soon be a hard error. Also, I'm using nightly rust.

Compiling opencl v0.3.0-dev (https://github.com/luqmana/rust-opencl.git#60d5956c)
.../master/src/hl.rs:841:5: 841:60 warning: the trait core::marker::Sized is not implemented for the type Self [E0277]
.../master/src/hl.rs:841 fn num_dimensions(dummy_self: Option) -> cl_uint;
.../master/src/hl.rs:841:5: 841:60 help: run rustc --explain E0277 to see a detailed explanation
.../master/src/hl.rs:841:5: 841:60 note: Self does not have a constant size known at compile-time
.../master/src/hl.rs:841 fn num_dimensions(dummy_self: Option) -> cl_uint;
.../master/src/hl.rs:841:5: 841:60 note: this warning results from recent bug fixes and clarifications; it will become a HARD ERROR in the next release. See RFC 1214 for details.
.../master/src/hl.rs:841 fn num_dimensions(dummy_self: Option) -> cl_uint;
.../master/src/hl.rs:841:5: 841:60 note: required by core::option::Option
.../master/src/hl.rs:841 fn num_dimensions(dummy_self: Option) -> cl_uint;

I was doing a few experiments with running hundreds of tasks each enqueueing and waiting on kernels before sending data back to the main task. And this ran head first into an expected problem with light weight threads. You can't block them and expect things to work correctly.

OpenCL has one way of working around this, The use of a callbacks. If you can setup a callback to do a message send when an event completes there is no need to do a event wait.

This would look something like this:

extern fn trampoline(_: cl_event, _: cl_int, arg: *libc::c_void)
{
    println(format!("trampoline"));
    let f = unsafe {
        let f: ~Cell<&fn()> = cast::transmute(arg);
        f.take()
    };

    f();
}

impl Event {
    #[fixed_stack_segment] #[inline(never)]
    fn callback(&self, cn_type :cl_uint, f: extern "C" fn(cl_event, cl_int, *libc::c_void), arg: *libc::c_void)
    {
        unsafe {
            clSetEventCallback(self.event,
                               cn_type,
                               f,
                               arg);
        }
    }

    fn rwait(&self) {
        let (p, c) : (PortOne<()>, ChanOne<()>) = oneshot();
        let c = Cell::new(c);
        let f = ~Cell::new(|| {c.take().send(())});
        unsafe {
            self.callback(CL_COMPLETE, trampoline, cast::transmute(f));
        }
        p.recv();
    }
}

I would not be writing this as an issue if that worked. The rust scheduler relies on some thread local storage to be set for it to work. So as soon as the trampoline fires an abort() occurs.

OpenCL does not offer a callback to initialize it's threads, so I can't see an easy way to set this thread local storage.

There are probably a few alternatives that could work instead of using channels. Using a pipe could work, the callback writes a byte to it, and the waiting function uses the native rust runtime read on the pipe. That sounds like an extremely round about and slow mechanise.

We should probably have a licensing agreement as part of the repo. Using the dual Apache MIT license that rust core uses makes the most sense to me.

I have the following compilation error :

src/mem.rs:4:32: 4:41 error: unresolved import `std::marker::PhantomFn`. There is no `PhantomFn` in `std::marker`
src/mem.rs:4 use std::marker::{PhantomData, PhantomFn};
                                            ^~~~~~~~~
src/error.rs:5:5: 5:28 error: unresolved import `std::num::FromPrimitive`. There is no `FromPrimitive` in `std::num`
src/error.rs:5 use std::num::FromPrimitive;
                   ^~~~~~~~~~~~~~~~~~~~~~~

Trying to build OpenCL with current master (1d40fd4) yields a plethora of errors, listed at http://itdaniher.com/p?PSFq. Working through these is on my todo list, but I figured I'd open an issue on the off chance someone else's made steps to bring OpenCL up to date in the past three weeks.

Environment

System: Arch Linux (up to date)
Rust: 0.10
rust-opencl: HEAD (2d4b1f7), libc imports backported to rust 0.10
OpenCL platform: pocl HEAD (56b8f47)

Related issue

See pocl/pocl#74

Description

Do not run test suite in parallel, because (as far as I know) OpenCL is not supposed to be thread safe for all used operations.

Solution

Set RUST_TEST_TASKS=1 environment variable for the tests. The Makefile would be a good place to do so.

TODO

Is rust-opencl really using violating thread requirements?

In cl.rs, all the constants are defined as statics instead of consts, which gets annoying if you're trying to wrap the values in things like the bitmasks! macro. Is there a reason they're defined this way?

I get this kind of output from opencl::hl::Device.device_type(): �

It would be nice to have one.

Under the nightly build of the rust compiler, a2866e387 2015-11-30, this library no longer compiles, giving the following error:

src/ext.rs:201:9: 201:15 error: a type named `std` has already been imported in this module [E0251]
src/ext.rs:201     use cl::*;
                   ^~~~~~
src/ext.rs:201:9: 201:15 help: run `rustc --explain E0251` to see a detailed explanation
src/hl.rs:14:5: 14:11 error: a type named `std` has already been imported in this module [E0251]
src/hl.rs:14 use cl::*;
             ^~~~~~
src/hl.rs:14:5: 14:11 help: run `rustc --explain E0251` to see a detailed explanation
error: aborting due to 2 previous errors
Could not compile `opencl`.

Running rustc --explain E0251 gives the following explanation:

Two items of the same name cannot be imported without rebinding one of the
items under a new local name.

An example of this error:

```
use foo::baz;
use bar::*; // error, do `use foo::baz as quux` instead on the previous line

fn main() {}

mod foo {
    pub struct baz;
}

mod bar {
    pub mod baz {}
}
```

I've fixed this locally, however I've opened this issue as documentation.

Here's the failure:

task <unnamed> failed at 'Test failure in y: expected ~[1, 2, 3, 4, 5], got ~[5, 0, 0, 0, 0]', vector.rs:212

I wonder if the representation of unique vectors has changed from when I originally wrote this code. The right thing to do for now may be to just remove the high level unique vector wrappers, since to use them we really need stronger support for natively running Rust on the GPU.

In line with pyopencl, it would be very useful to have support for prefix sums and ad hoc elementwise kernels.
Do you consider rust-opencl the right place, or would you rather like to see a separate library to support such higher level functionality?

Right now, Context::create_command_queue always enables profiling information. We should make this configurable, either as an optional parameter, a separate function, or maybe through some kind of options type.

I am evaluating writing a project in Rust instead of C++. I am not sure if rust-opencl works with the stable Rust compilers. I have tried compiling rust-opencl with rustc 1.1.0 but I am getting "unstable feature" error.

Thanks,

Geoffrey

Is it possible to set arguments with qualifiers other than global?

Thanks