luqmana / rust-opencl Goto Github PK
View Code? Open in Web Editor NEWOpenCL bindings for Rust.
License: Other
OpenCL bindings for Rust.
License: Other
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:
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.
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.
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)
See pocl/pocl#74
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.
Set RUST_TEST_TASKS=1
environment variable for the tests. The Makefile would be a good place to do so.
Is rust-opencl really using violating thread requirements?
$ rustc --version
rustc 1.5.0-nightly (cff041170 2015-09-17)
$ git clone https://github.com/luqmana/rust-opencl.git
$ cd rust-opencl
$ cargo build --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
Compiling libc v0.1.10
Running `rustc ~/.cargo/registry/src/github.com-0a35038f75765ae4/libc-0.1.10/rust/src/liblibc/lib.rs --crate-name libc --crate-type lib -g --cfg feature=\"cargo-build\" --cfg feature=\"default\" -C metadata=144c435538abd757 -C extra-filename=-144c435538abd757 --out-dir ~/workspace/rust/rust-opencl/target/debug/deps --emit=dep-info,link -L dependency=~/workspace/rust/rust-opencl/target/debug/deps -L dependency=~/workspace/rust/rust-opencl/target/debug/deps --cap-lints allow`
Compiling log v0.3.2
Running `rustc ~/.cargo/registry/src/github.com-0a35038f75765ae4/log-0.3.2/src/lib.rs --crate-name log --crate-type lib -g -C metadata=f18a3e885170bd3f -C extra-filename=-f18a3e885170bd3f --out-dir ~/workspace/rust/rust-opencl/target/debug/deps --emit=dep-info,link -L dependency=~/workspace/rust/rust-opencl/target/debug/deps -L dependency=~/workspace/rust/rust-opencl/target/debug/deps --extern libc=~/workspace/rust/rust-opencl/target/debug/deps/liblibc-144c435538abd757.rlib --cap-lints allow`
Compiling opencl v0.3.0-dev (file:///~/workspace/rust/rust-opencl)
Running `rustc src/lib.rs --crate-name opencl --crate-type lib -g --out-dir ~/workspace/rust/rust-opencl/target/debug --emit=dep-info,link -L dependency=~/workspace/rust/rust-opencl/target/debug -L dependency=~/workspace/rust/rust-opencl/target/debug/deps --extern log=~/workspace/rust/rust-opencl/target/debug/deps/liblog-f18a3e885170bd3f.rlib --extern libc=~/workspace/rust/rust-opencl/target/debug/deps/liblibc-144c435538abd757.rlib`
src/ext.rs:67:15: 67:73 error: the trait `core::clone::Clone` is not implemented for the type `extern "C" fn(*mut libc::types::common::c95::c_void, u64, u64, *const cl::cl_image_format, u32, u64, *mut libc::types::common::c95::c_void, *mut u64)` [E0277]
src/ext.rs:67 $(pub $function: (extern fn ($($arg : $arg_type),+) -> $ret)),+
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/ext.rs:65:24: 65:29 note: in this expansion of #[derive_Clone] (defined in src/ext.rs)
src/ext.rs:20:9: 20:70 note: in this expansion of ext_struct_def! (defined in src/ext.rs)
src/ext.rs:253:5: 263:6 note: in this expansion of cl_extension_loader! (defined in src/ext.rs)
src/ext.rs:67:15: 67:73 help: run `rustc --explain E0277` to see a detailed explanation
src/ext.rs:67:15: 67:73 note: required by `core::clone::Clone::clone`
error: aborting due to previous error
Could not compile `opencl`.
Caused by:
Process didn't exit successfully: `rustc src/lib.rs --crate-name opencl --crate-type lib -g --out-dir ~/workspace/rust/rust-opencl/target/debug --emit=dep-info,link -L dependency=~/workspace/rust/rust-opencl/target/debug -L dependency=~/workspace/rust/rust-opencl/target/debug/deps --extern log=~/workspace/rust/rust-opencl/target/debug/deps/liblog-f18a3e885170bd3f.rlib --extern libc=~/workspace/rust/rust-opencl/target/debug/deps/liblibc-144c435538abd757.rlib` (exit code: 101)
In cl.rs, all the constants are defined as static
s instead of const
s, 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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.