cogciprocate/ocl

OpenCL for Rust

ocl

Documentation | Change Log

Pure OpenCL™ bindings and interfaces for Rust.

Goals

To provide:

• A simple and intuitive interface to OpenCL devices
• The full functionality and power of the OpenCL API
• An absolute minimum of boilerplate
• Zero or virtually zero performance overhead
• Thread-safe and automatic management of API pointers and resources

Usage

Ensure that an OpenCL library is installed for your platform and that clinfo or some other diagnostic command will run. Add the following to your project's Cargo.toml:

[dependencies]
ocl = "0.19"

And add the following to your crate root (lib.rs or main.rs):

extern crate ocl;

Example

From examples/trivial.rs:

extern crate ocl;
use ocl::ProQue;

fn trivial() -> ocl::Result<()> {
    let src = r#"
        __kernel void add(__global float* buffer, float scalar) {
            buffer[get_global_id(0)] += scalar;
        }
    "#;

    let pro_que = ProQue::builder()
        .src(src)
        .dims(1 << 20)
        .build()?;

    let buffer = pro_que.create_buffer::<f32>()?;

    let kernel = pro_que.kernel_builder("add")
        .arg(&buffer)
        .arg(10.0f32)
        .build()?;

    unsafe { kernel.enq()?; }

    let mut vec = vec![0.0f32; buffer.len()];
    buffer.read(&mut vec).enq()?;

    println!("The value at index [{}] is now '{}'!", 200007, vec[200007]);
    Ok(())
}

See the the remainder of examples/trivial.rs for more information about how this library leverages Rust's zero-cost abstractions to provide the full power and performance of the C API in a simple package.

Recent Changes

• 0.18.0: Creating a Kernel now requires the use of the new KernelBuilder. See the change log for more information.

Introduction to OpenCL

For a quick but thorough primer on the basics of OpenCL, please see Matthew Scarpino's excellent article, 'A Gentle Introduction to OpenCL' at drdobbs.com (his book is great too).

Diving Deeper

Already familiar with the standard OpenCL core API? See the ocl-core crate for access to the complete feature set in the conventional API style with Rust's safety and convenience.

Version Support

OpenCL versions 1.1 and above are supported. OpenCL version 1.0 is not supported due to its inherent thread unsafety.

Vulkan™ and the Future

The OpenCL API already posesses all of the new attributes of the Vulkan API such as low-overhead, high performance, and unfettered hardware access. For all practical purposes, Vulkan is simply a graphics-focused superset of OpenCL's features (sorta kinda). OpenCL 2.1+ and Vulkan kernels/shaders now both compile into SPIR-V making the device side of things the same. I wouldn't be suprised if most driver vendors implement the two host APIs identically.

In the future it's possible the two may completely merge (or that Vulkan will absorb OpenCL). Whatever happens, nothing will change as far as the front end of this library is concerned. This library will maintain its focus on the compute side of things.

License

Licensed under either of:

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

“OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission by Khronos.”
“Vulkan and the Vulkan logo are trademarks of the Khronos Group Inc.”

ocl's Issues

Problem loading OpenCL 2.0 on Intel i7

Ok so I tried the simple example of just listing my platform. Got some errors and other problems. So first on my system I've installed the Intel OpenCL 2.0 extension. When I do clinfo in terminal I get:

 Platform ID:					 0x201f9e0
  Name:						 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
  Vendor:					 Intel(R) Corporation
  Device OpenCL C version:			 OpenCL C 2.0 
  Driver version:				 1.2.0.18
  Profile:					 FULL_PROFILE
  Version:					 OpenCL 2.1 (Build 18)
  Extensions:					 cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64 cl_khr_image2d_from_buffer 

Running the example for the platform in Rust gave me:

Platform:
    Profile: FULL_PROFILE
    Version: OpenCL 1.2 LINUX
    Name: Intel(R) OpenCL
    Vendor: Intel(R) Corporation
    Extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64

and for the device:

Name: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
    Vendor: Intel(R) Corporation
    DriverVersion: 1.2.0.43
    Profile: FULL_PROFILE
    Version: OpenCL 1.2 (Build 43)
    Extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64 
    Platform: PlatformId(0x7f30dba150b0)
    DoubleFpConfig: FP_DENORM | FP_INF_NAN | FP_ROUND_TO_NEAREST | FP_ROUND_TO_ZERO | FP_ROUND_TO_INF | FP_FMA
    HalfFpConfig: 

Additionally the HalffpConfig produced the error:

################################ OPENCL ERROR ############################### 

Error executing function: clGetDeviceInfo  

Status error code: CL_INVALID_VALUE (-30)  

Please visit the following url for more information: 

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetDeviceInfo.html#errors  

First is it intentional there is no option to loading the 2.0 version or potentially this might mean that my environment is not pointing to it correctly.
Also any idea about the HalfFpConfig?

Fix broken links in documentation

For example, https://docs.rs/ocl/0.13.1/ocl/struct.Buffer.html#method.read has a link to https://docs.rs/ocl/0.13.1/ocl/struct.BufferCmd, which doesn't exist there.

Unused imports warning

rust-ocl\src\util.rs:12:35: 12:46 warning: unused import, #[warn(unused_imports)] on by default
rust-ocl\src\util.rs:12 use num::{Integer, FromPrimitive, ToPrimitive};
                                                          ^~~~~~~~~~~
rust-ocl\src\core\functions.rs:14:5: 14:18 warning: unused import, #[warn(unused_imports)] on by default
rust-ocl\src\core\functions.rs:14 use std::io::Read;
                                      ^~~~~~~~~~~~~

No Cargo Release Since Breaking API Change

Hi, looks like since the breaking change a few months back, there hasn't been a version bump on Cargo. I discovered this because some examples weren't running.

The examples with that PR will now point to the base repo, so they work again.. but is it time for a new Cargo push? :)

Thanks!

Null terminators present in Strings

extern crate ocl;

use ocl::*;

fn main() {
    for platform in Platform::list() {
        println!("platform: {:?}", platform.name());
        for device in Device::list_all(&platform) {
            println!("device: {:?}", device.name());
        }
    }
}

got

$ cargo run
     Running `target/debug/test`
platform: "Intel(R) OpenCL\u{0}"
device: "Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz\u{0}"

expected

$ cargo run
     Running `target/debug/test`
platform: "Intel(R) OpenCL"
device: "Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz"

In nine or ten hours I can test this with Nvidia's ICD too, right now I only have my laptop.

EDIT: So at a minimum, the following methods return null terminated strings with Intel's ICD:

• Platform::name()
• Platform::profile()
• Platform::version()
• Platform::vendor()
• Platform::extensions()
• Device::name()
• Device::vendor()

The following methods do not:

• Platform::into()
• Device::into()
• Device::to_string()

(test program here)

Releasing buffers

Hey,

I don't see any way of explicitly releasing a buffer and I don't see either an implicit release via the drop trait.
Am I wrong ?

I can implement it if you tell me what you would prefer between implicit and explicit release.

Cheers

NVIDIA drivers - `examples/events.rs` panic

Now panics examples/events :)

Rest of examples works fine.

Example codes segfaults with SIGSEV

The code segfaults while creating buffers.

For instance, the code info.rs segfaults with the following backtrace

#0  0x0000000000000000 in ?? ()
#1  0x000055555557f947 in ocl_core::functions::enqueue_fill_buffer<f32> (command_queue=0x7fffffffd458, buffer=0x7fffffffd450, 
    pattern=0, offset=0, len=2097152, wait_list=..., new_event=..., device_version=...)
    at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ocl-core-0.2.1/src/functions.rs:2081
#2  0x0000555555573860 in ocl::standard::buffer::{{impl}}::enq<f32> (self=...)
    at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ocl-0.11.0/src/standard/buffer.rs:439
#3  0x000055555556a795 in ocl::standard::buffer::{{impl}}::new<f32,&&ocl::standard::spatial_dims::SpatialDims> (queue=0x7fffffffdfe8, 
    flags=..., dims=0x7fffffffd758, data=...)
    at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ocl-0.11.0/src/standard/buffer.rs:497
#4  0x000055555556328a in ocl::standard::pro_que::{{impl}}::create_buffer<f32> (self=0x7fffffffdfb8)
    at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/ocl-0.11.0/src/standard/pro_que.rs:317
#5  0x0000555555583e9c in ocl_test::main () at ~/sandbox/rust/ocl_test/src/main.rs:17
#6  0x000055555561a427 in __rust_maybe_catch_panic ()
#7  0x0000555555611502 in std::rt::lang_start::haaae1186de9de8cb ()
#8  0x0000555555585da4 in main ()

Running Valgrind gives the following error

$ valgrind target/debug/ocl_test                                                                               
==3923== Memcheck, a memory error detector
==3923== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3923== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3923== Command: target/debug/ocl_test
==3923== 
==3923== Jump to the invalid address stated on the next line
==3923==    at 0x0: ???
==3923==    by 0x12785F: _$LT$ocl..standard..buffer..BufferCmd$LT$$u27$b$C$$u20$T$GT$$GT$::enq::hec4641e5d0c38db2 (buffer.rs:439)
==3923==    by 0x11E794: _$LT$ocl..standard..buffer..Buffer$LT$T$GT$$GT$::new::h60ba2c1a6884faf5 (buffer.rs:497)
==3923==    by 0x117289: ocl::standard::pro_que::ProQue::create_buffer::hfc25f251ff0e0b49 (pro_que.rs:317)
==3923==    by 0x137E9B: ocl_test::main::hd0ca2eec2b098483 (main.rs:17)
==3923==    by 0x1CE426: __rust_maybe_catch_panic (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923==    by 0x1C5501: std::rt::lang_start::haaae1186de9de8cb (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923==    by 0x139DA3: main (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==3923== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==3923==  Bad permissions for mapped region at address 0x0
==3923==    at 0x0: ???
==3923==    by 0x12785F: _$LT$ocl..standard..buffer..BufferCmd$LT$$u27$b$C$$u20$T$GT$$GT$::enq::hec4641e5d0c38db2 (buffer.rs:439)
==3923==    by 0x11E794: _$LT$ocl..standard..buffer..Buffer$LT$T$GT$$GT$::new::h60ba2c1a6884faf5 (buffer.rs:497)
==3923==    by 0x117289: ocl::standard::pro_que::ProQue::create_buffer::hfc25f251ff0e0b49 (pro_que.rs:317)
==3923==    by 0x137E9B: ocl_test::main::hd0ca2eec2b098483 (main.rs:17)
==3923==    by 0x1CE426: __rust_maybe_catch_panic (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923==    by 0x1C5501: std::rt::lang_start::haaae1186de9de8cb (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923==    by 0x139DA3: main (in ~/sandbox/rust/ocl_test/target/debug/ocl_test)
==3923== 
==3923== HEAP SUMMARY:
==3923==     in use at exit: 61,995 bytes in 472 blocks
==3923==   total heap usage: 2,646 allocs, 2,174 frees, 1,315,734 bytes allocated
==3923== 
==3923== LEAK SUMMARY:
==3923==    definitely lost: 72 bytes in 1 blocks
==3923==    indirectly lost: 47 bytes in 1 blocks
==3923==      possibly lost: 1,256 bytes in 18 blocks
==3923==    still reachable: 60,620 bytes in 452 blocks
==3923==                       of which reachable via heuristic:
==3923==                         stdstring          : 1,033 bytes in 25 blocks
==3923==                         newarray           : 3,120 bytes in 4 blocks
==3923==         suppressed: 0 bytes in 0 blocks
==3923== Rerun with --leak-check=full to see details of leaked memory
==3923== 
==3923== For counts of detected and suppressed errors, rerun with: -v
==3923== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Tested on Intel as well as PoCL implementation of OpenCL.
Other information: Manjaro linux, linux kernel 4.4.20-1

Should Kernel implement Clone?

The docs for Kernel say "Reference counter now managed automatically", but as far as I can tell, Kernel doesn't implement clone, so there's no way to make use of this.

btw, I'm in love with this library. I likely wouldn't have learned opencl if it weren't for this crate!

Image example not complete

In the image example misses a queue().finish()if I am not mistaken.

At least it was necessary to make a slighlty adjust, GPU only work for me.

Abort trap triggered when calling `read` from large buffer after long kernel compute.

I've found that calling read on a large buffer after that buffer has been filled from a kernel that took a long time to run causes OSX to abort.

Reproduction steps here: https://github.com/TyOverby/ocl-repro

glxinfo

name of display: /private/tmp/com.apple.launchd.hPikpBRB8V/org.macosforge.xquartz:0
display: /private/tmp/com.apple.launchd.hPikpBRB8V/org.macosforge.xquartz:0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Intel Inc.
OpenGL renderer string: Intel Iris Pro OpenGL Engine
OpenGL version string: 2.1 INTEL-10.22.29
OpenGL shading language version string: 1.20
OpenGL extensions:
    GL_APPLE_aux_depth_stencil, GL_APPLE_client_storage, 
    GL_APPLE_element_array, GL_APPLE_fence, GL_APPLE_float_pixels, 
    GL_APPLE_flush_buffer_range, GL_APPLE_flush_render, 
    GL_APPLE_object_purgeable, GL_APPLE_packed_pixels, GL_APPLE_pixel_buffer, 
    GL_APPLE_rgb_422, GL_APPLE_row_bytes, GL_APPLE_specular_vector, 
    GL_APPLE_texture_range, GL_APPLE_transform_hint, 
    GL_APPLE_vertex_array_object, GL_APPLE_vertex_array_range, 
    GL_APPLE_vertex_point_size, GL_APPLE_vertex_program_evaluators, 
    GL_APPLE_ycbcr_422, GL_ARB_color_buffer_float, GL_ARB_depth_buffer_float, 
    GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, 
    GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
    GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
    GL_ARB_framebuffer_sRGB, GL_ARB_half_float_pixel, 
    GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, GL_ARB_multisample, 
    GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, 
    GL_ARB_seamless_cube_map, GL_ARB_shader_objects, 
    GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, GL_ARB_shadow, 
    GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
    GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map, 
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
    GL_ARB_texture_rg, GL_ARB_transpose_matrix, GL_ARB_vertex_array_bgra, 
    GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, 
    GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_separate_stencil, 
    GL_ATI_texture_env_combine3, GL_ATI_texture_float, 
    GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, 
    GL_EXT_debug_label, GL_EXT_debug_marker, GL_EXT_draw_buffers2, 
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, 
    GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_multisample_blit_scaled, 
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, 
    GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, 
    GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 
    GL_EXT_packed_float, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, 
    GL_EXT_texture_array, GL_EXT_texture_compression_dxt1, 
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_add, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_integer, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
    GL_EXT_texture_sRGB_decode, GL_EXT_texture_shared_exponent, 
    GL_EXT_timer_query, GL_EXT_transform_feedback, GL_EXT_vertex_array_bgra, 
    GL_IBM_rasterpos_clip, GL_NV_blend_square, GL_NV_conditional_render, 
    GL_NV_depth_clamp, GL_NV_fog_distance, GL_NV_light_max_exponent, 
    GL_NV_texgen_reflection, GL_NV_texture_barrier, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod

80 GLX Visuals
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x022 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  8  0  0  0  0  0 0 None
0x0c1 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 Slow
0x0c2 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0 16 1 Slow
0x0c3 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  0  0  0  0  0  0 0 Slow
0x0c4 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  0  0  0  0  0 16 1 Slow
0x0c5 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 Slow
0x0c6 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0 16 1 Slow
0x0c7 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  8  0  0  0  0  0 0 Slow
0x0c8 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  8  0  0  0  0 16 1 Slow
0x0c9 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 Slow
0x0ca 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0 16 1 Slow
0x0cb 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  0  0  0  0  0  0 0 Slow
0x0cc 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  0  0  0  0  0 16 1 Slow
0x0cd 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 Slow
0x0ce 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0 16 1 Slow
0x0cf 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  8  0  0  0  0  0 0 Slow
0x0d0 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  8  0  0  0  0 16 1 Slow
0x0d1 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  0  0  0  0  0  0 0 Slow
0x0d2 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  0  0  0  0  0 16 1 Slow
0x0d3 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  0  0  0  0  0  0 0 Slow
0x0d4 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  0  0  0  0  0 16 1 Slow
0x0d5 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  8  0  0  0  0  0 0 Slow
0x0d6 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  8  0  0  0  0 16 1 Slow
0x0d7 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  8  0  0  0  0  0 0 Slow
0x0d8 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  8  0  0  0  0 16 1 Slow
0x0d9 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  0  0  0  0  0  0 0 Slow
0x0da 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  0  0  0  0  0 16 1 Slow
0x0db 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  0  0  0  0  0  0 0 Slow
0x0dc 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  0  0  0  0  0 16 1 Slow
0x0dd 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  8  0  0  0  0  0 0 Slow
0x0de 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  8  0  0  0  0 16 1 Slow
0x0df 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  8  0  0  0  0  0 0 Slow
0x0e0 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  8  0  0  0  0 16 1 Slow
0x0e1 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0e2 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0e3 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  0  0  0  0  0  0 0 None
0x0e4 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  0  0  0  0  0  8 1 None
0x0e5 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  0  0  0  0  0  0 0 None
0x0e6 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  0  0  0  0  0  8 1 None
0x0e7 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 None
0x0e8 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  8 1 None
0x0e9 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  8  0  0  0  0  0 0 None
0x0ea 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  8  0  0  0  0  8 1 None
0x0eb 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0ec 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x0ed 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0ee 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0ef 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  0  0  0  0  0  0 0 None
0x0f0 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  0  0  0  0  0  8 1 None
0x0f1 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  0  0  0  0  0  0 0 None
0x0f2 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  0  0  0  0  0  8 1 None
0x0f3 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 None
0x0f4 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  8 1 None
0x0f5 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  8  0  0  0  0  8 1 None
0x0f6 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0f7 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x0f8 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  0  0  0  0  0  0 0 None
0x0f9 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  0  0  0  0  0  8 1 None
0x0fa 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  0  0  0  0  0  0 0 None
0x0fb 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  0  0  0  0  0  8 1 None
0x0fc 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  0  0  0  0  0  0 0 None
0x0fd 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  0  0  0  0  0  8 1 None
0x0fe 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  8  0  0  0  0  0 0 None
0x0ff 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  8  0  0  0  0  8 1 None
0x100 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  8  0  0  0  0  0 0 None
0x101 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  8  0  0  0  0  8 1 None
0x102 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  8  0  0  0  0  0 0 None
0x103 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  8  0  0  0  0  8 1 None
0x104 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  0  0  0  0  0  0 0 None
0x105 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  0  0  0  0  0  8 1 None
0x106 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  0  0  0  0  0  0 0 None
0x107 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  0  0  0  0  0  8 1 None
0x108 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  0  0  0  0  0  0 0 None
0x109 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  0  0  0  0  0  8 1 None
0x10a 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  8  0  0  0  0  0 0 None
0x10b 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  8  0  0  0  0  8 1 None
0x10c 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  8  0  0  0  0  0 0 None
0x10d 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  8  0  0  0  0  8 1 None
0x10e 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  8  0  0  0  0  0 0 None
0x10f 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  8  0  0  0  0  8 1 None

128 GLXFBConfigs:
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x041 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 Slow
0x042 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0 16 1 Slow
0x043 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  0  0  0  0  0  0 0 Slow
0x044 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  0  0  0  0  0 16 1 Slow
0x045 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 Slow
0x046 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0 16 1 Slow
0x047 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  8  0  0  0  0  0 0 Slow
0x048 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 32  8  0  0  0  0 16 1 Slow
0x049 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 Slow
0x04a 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0 16 1 Slow
0x04b 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  0  0  0  0  0  0 0 Slow
0x04c 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  0  0  0  0  0 16 1 Slow
0x04d 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 Slow
0x04e 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0 16 1 Slow
0x04f 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  8  0  0  0  0  0 0 Slow
0x050 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 32  8  0  0  0  0 16 1 Slow
0x051 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  0  0  0  0  0  0 0 Slow
0x052 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  0  0  0  0  0 16 1 Slow
0x053 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  0  0  0  0  0  0 0 Slow
0x054 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  0  0  0  0  0 16 1 Slow
0x055 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  8  0  0  0  0  0 0 Slow
0x056 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4  0  8  0  0  0  0 16 1 Slow
0x057 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  8  0  0  0  0  0 0 Slow
0x058 24 tc  1  32  0 r  . .   8  8  8  8 .  .  4 32  8  0  0  0  0 16 1 Slow
0x059 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  0  0  0  0  0  0 0 Slow
0x05a 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  0  0  0  0  0 16 1 Slow
0x05b 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  0  0  0  0  0  0 0 Slow
0x05c 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  0  0  0  0  0 16 1 Slow
0x05d 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  8  0  0  0  0  0 0 Slow
0x05e 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4  0  8  0  0  0  0 16 1 Slow
0x05f 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  8  0  0  0  0  0 0 Slow
0x060 24 tc  1  32  0 r  y .   8  8  8  8 .  .  4 32  8  0  0  0  0 16 1 Slow
0x061  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0  0  0  0  0  0  0  0 0 None
0x062  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0  0  0  0  0  0  0  8 1 None
0x063  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 16  0  0  0  0  0  0 0 None
0x064  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 16  0  0  0  0  0  8 1 None
0x065  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 24  0  0  0  0  0  0 0 None
0x066  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 24  0  0  0  0  0  8 1 None
0x067 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x068 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x069 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  0  0  0  0  0  0 0 None
0x06a 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  0  0  0  0  0  8 1 None
0x06b 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  0  0  0  0  0  0 0 None
0x06c 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  0  0  0  0  0  8 1 None
0x06d  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0  0  8  0  0  0  0  0 0 None
0x06e  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0  0  8  0  0  0  0  8 1 None
0x06f  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 16  8  0  0  0  0  0 0 None
0x070  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 16  8  0  0  0  0  8 1 None
0x071  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 24  8  0  0  0  0  0 0 None
0x072  0 tc  1  16  0 r  . .   5  5  5  1 .  .  0 24  8  0  0  0  0  8 1 None
0x073 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 None
0x074 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0  0  8  0  0  0  0  8 1 None
0x075 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  8  0  0  0  0  0 0 None
0x076 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 16  8  0  0  0  0  8 1 None
0x077 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x078 24 tc  1  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x079  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0  0  0  0  0  0  0  0 0 None
0x07a  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0  0  0  0  0  0  0  8 1 None
0x07b  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 16  0  0  0  0  0  0 0 None
0x07c  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 16  0  0  0  0  0  8 1 None
0x07d  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 24  0  0  0  0  0  0 0 None
0x07e  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 24  0  0  0  0  0  8 1 None
0x07f 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x080 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x081 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  0  0  0  0  0  0 0 None
0x082 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  0  0  0  0  0  8 1 None
0x083 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  0  0  0  0  0  0 0 None
0x084 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  0  0  0  0  0  8 1 None
0x085  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0  0  8  0  0  0  0  0 0 None
0x086  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0  0  8  0  0  0  0  8 1 None
0x087  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 16  8  0  0  0  0  0 0 None
0x088  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 16  8  0  0  0  0  8 1 None
0x089  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 24  8  0  0  0  0  0 0 None
0x08a  0 tc  1  16  0 r  y .   5  5  5  1 .  .  0 24  8  0  0  0  0  8 1 None
0x08b 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  0 0 None
0x08c 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0  0  8  0  0  0  0  8 1 None
0x08d 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  8  0  0  0  0  0 0 None
0x08e 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 16  8  0  0  0  0  8 1 None
0x08f 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x090 24 tc  1  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x091  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2  0  0  0  0  0  0  0 0 None
0x092  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2  0  0  0  0  0  0  8 1 None
0x093  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 16  0  0  0  0  0  0 0 None
0x094  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 16  0  0  0  0  0  8 1 None
0x095  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 24  0  0  0  0  0  0 0 None
0x096  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 24  0  0  0  0  0  8 1 None
0x097 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  0  0  0  0  0  0 0 None
0x098 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  0  0  0  0  0  8 1 None
0x099 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  0  0  0  0  0  0 0 None
0x09a 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  0  0  0  0  0  8 1 None
0x09b 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  0  0  0  0  0  0 0 None
0x09c 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  0  0  0  0  0  8 1 None
0x09d  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2  0  8  0  0  0  0  0 0 None
0x09e  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2  0  8  0  0  0  0  8 1 None
0x09f  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 16  8  0  0  0  0  0 0 None
0x0a0  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 16  8  0  0  0  0  8 1 None
0x0a1  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 24  8  0  0  0  0  0 0 None
0x0a2  0 tc  1  16  0 r  . .   5  5  5  1 .  .  2 24  8  0  0  0  0  8 1 None
0x0a3 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  8  0  0  0  0  0 0 None
0x0a4 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2  0  8  0  0  0  0  8 1 None
0x0a5 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  8  0  0  0  0  0 0 None
0x0a6 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 16  8  0  0  0  0  8 1 None
0x0a7 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  8  0  0  0  0  0 0 None
0x0a8 24 tc  1  32  0 r  . .   8  8  8  8 .  .  2 24  8  0  0  0  0  8 1 None
0x0a9  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2  0  0  0  0  0  0  0 0 None
0x0aa  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2  0  0  0  0  0  0  8 1 None
0x0ab  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 16  0  0  0  0  0  0 0 None
0x0ac  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 16  0  0  0  0  0  8 1 None
0x0ad  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 24  0  0  0  0  0  0 0 None
0x0ae  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 24  0  0  0  0  0  8 1 None
0x0af 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  0  0  0  0  0  0 0 None
0x0b0 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  0  0  0  0  0  8 1 None
0x0b1 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  0  0  0  0  0  0 0 None
0x0b2 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  0  0  0  0  0  8 1 None
0x0b3 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  0  0  0  0  0  0 0 None
0x0b4 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  0  0  0  0  0  8 1 None
0x0b5  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2  0  8  0  0  0  0  0 0 None
0x0b6  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2  0  8  0  0  0  0  8 1 None
0x0b7  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 16  8  0  0  0  0  0 0 None
0x0b8  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 16  8  0  0  0  0  8 1 None
0x0b9  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 24  8  0  0  0  0  0 0 None
0x0ba  0 tc  1  16  0 r  y .   5  5  5  1 .  .  2 24  8  0  0  0  0  8 1 None
0x0bb 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  8  0  0  0  0  0 0 None
0x0bc 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2  0  8  0  0  0  0  8 1 None
0x0bd 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  8  0  0  0  0  0 0 None
0x0be 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 16  8  0  0  0  0  8 1 None
0x0bf 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  8  0  0  0  0  0 0 None
0x0c0 24 tc  1  32  0 r  y .   8  8  8  8 .  .  2 24  8  0  0  0  0  8 1 None

examples/info panic

This example raises panic with

thread '<main>' panicked at 'assertion failed: (left == right) (left: 4, right: 8)', rust-ocl\src\util.rs:196

on any of following commented function:

                print_context_info(&context);
                // print_queue_info(&queue);
                // print_buffer_info(&buffer);
                // print_image_info(&image);
                // print_sampler_info(&sampler);
                print_program_info(&program);
                // print_kernel_info(&kernel);
                // print_event_list_info(&event_list);
                // print_event_info(&event);

Windows 7 x64, OCL runtimes: nvidia 1.2, intel 2.0, intel 1.2.

Tests fail on OS X

No idea where to start.

running 2 tests
thread 'thread '<unnamed><unnamed>' panicked at '' panicked at 'assertion failed: `(left == right)` (left: `326`, right: `306`)assertion failed: `(left == right)` (left: `326`, right: `316`)', ', src/tests.rssrc/tests.rs::3232

libc++abi.dylib: libc++abi.dylib: terminating with uncaught foreign exceptionterminating with uncaught foreign exception

Make destruction more robust

Currently some things impl Drop and others don't, leaving some of the job to the consumer. Evaluate exactly how best to handle shared references to various pointers such that they can be released atomically.

Major 'Envoy' rework and possible rename.

Give envoy more creation time control over which type of cl_buffer it represents, most likely defaulting to a buffer without any local storage. Various options will probably be declared in the usual, builder-style way (whatever people call that).

Possibly rename to 'Buffer'.

Where are the vector types?

E.g. cl_float3. Where are they? It kind of looks like they're not defined, which is problematic.

Example code does not compile

I'm getting compile errors for the example code on the main github page.

src/main.rs:1:21: 1:29 error: unresolved import `ocl::ProQueue`. There is no `ProQueue` in `ocl` [E0432]
src/main.rs:1 use ocl::{ Context, ProQueue, BuildOptions, SimpleDims, Envoy };
                                  ^~~~~~~~
src/main.rs:1:21: 1:29 help: run `rustc --explain E0432` to see a detailed explanation
src/main.rs:1:31: 1:43 error: unresolved import `ocl::BuildOptions`. There is no `BuildOptions` in `ocl` [E0432]
src/main.rs:1 use ocl::{ Context, ProQueue, BuildOptions, SimpleDims, Envoy };
                                            ^~~~~~~~~~~~
src/main.rs:1:31: 1:43 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to 2 previous errors
Could not compile `ocl_test`.

To learn more, run the command again with --verbose.

Even though it downloads and compiles the ocl dependency successfully, and clinfo seems to indicate opencl support is working just fine on my system.

What could be wrong? I'm guessing something has changed in the library recently, but the 'unresolved' objects seem to be in the library. I'm not yet familiar enough with Rust to say what's going on for sure.

How does one map buffers?

I see enqueue_map_buffer command in ocl_core module. What is the corresponding call in ocl? I went through the code of Buffer module and I couldn't find any calls to enqueue_map_buffer. Am I missing something?

Example for reading a scalar out

This is not a bug report at all, but I was curious, what is the recommended way to read a scalar shared in a kernel? I see that arg_scl can pass in a bunch of scalar OclPrm types, and they can also be passed in by creating a buffer out of their mutable reference. But if you try to read back from that buffer into the scalar ref, the buffer read method will expect a trait that is not implemented for scalar types:

error[E0277]: the trait bound `ocl::standard::buffer::ReadDst<'_, f64>: std::convert::From<&mut f64>` is not satisfied

What's the recommended way to do this?

Also, thanks for making this library. It's excellent already.

ocl-core doesn't compile on ARM platforms

This is more of a feature request than a bug report.

Compiling an arbitrary OpenCL program that uses ocl crate gives the following error while compiling ocl-core on an ARM device (odroid-XU4)

Compiling ocl-core v0.3.0 (file:///home/odroid/workspace/ubench_rust/ocl/ocl-core)
ocl/ocl-core/src/functions.rs:1202:85: 1202:92 error: the trait bound `std::vec::Vec<*const i8>: std::iter::FromIterator<*const u8>` is not satisfied [E0277]
ocl/ocl-core/src/functions.rs:1202     let kern_string_ptrs: Vec<*const i8> = src_strings.iter().map(|cs| cs.as_ptr()).collect();
                                                                                                                       ^~~~~~~
ocl/ocl-core/src/functions.rs:1202:85: 1202:92 help: run `rustc --explain E0277` to see a detailed explanation
ocl/ocl-core/src/functions.rs:1202:85: 1202:92 note: a collection of type `std::vec::Vec<*const i8>` cannot be built from an iterator over elements of type `*const u8`
ocl/ocl-core/src/functions.rs:1209:9: 1209:54 error: mismatched types [E0308]
ocl/ocl-core/src/functions.rs:1209         kern_string_ptrs.as_ptr() as *const *const i8,
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ocl/ocl-core/src/functions.rs:1209:9: 1209:54 help: run `rustc --explain E0308` to see a detailed explanation
ocl/ocl-core/src/functions.rs:1209:9: 1209:54 note: expected type `*const *const u8`
ocl/ocl-core/src/functions.rs:1209:9: 1209:54 note:    found type `*const *const i8`
ocl/ocl-core/src/functions.rs:1317:9: 1317:38 error: mismatched types [E0308]
ocl/ocl-core/src/functions.rs:1317         options.as_ptr() as *const i8,
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ocl/ocl-core/src/functions.rs:1317:9: 1317:38 help: run `rustc --explain E0308` to see a detailed explanation
ocl/ocl-core/src/functions.rs:1317:9: 1317:38 note: expected type `*const u8`
ocl/ocl-core/src/functions.rs:1317:9: 1317:38 note:    found type `*const i8`
error: aborting due to 3 previous errors
error: Could not compile `ocl-core`.

This is not due to bug in your code, but because the rust nightly is not entirely supported for arm. Check this issue here.

The fix I found with some google-fu is to use *const _ instead of *const i8 at these locations. I can confirm this solution compiles fine on ARM and on my laptop (x86_64).

I'll anyway send you a PR soon that fixes this issue. Could you wrap it in a feature and push it upstream?

More thoroughly test events

Ensure that events created by both kernels and reads/writes are valid. Ensure likewise for consuming event lists.

Match up all possible permutations (kernel -> read, kernel -> write, write -> kernel, write -> write, read -> read) etc...

Integrate find_folder crate for convenience

... to locate kernel files.

Can't compile image2 test with 0.11.0

     Running `rustc /home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs --crate-name ocl --crate-type lib -g -C metadata=5fed3a1901a87798 -C extra-filename=-5fed3a1901a87798 --out-dir /tmp/ocl/examples/images2/target/debug/deps --emit=dep-info,link -L dependency=/tmp/ocl/examples/images2/target/debug/deps -L dependency=/tmp/ocl/examples/images2/target/debug/deps --extern ocl_core=/tmp/ocl/examples/images2/target/debug/deps/libocl_core-9662442c01dbd188.rlib --extern rand=/tmp/ocl/examples/images2/target/debug/deps/librand-6fab17fc670a2bc8.rlib --extern bitflags=/tmp/ocl/examples/images2/target/debug/deps/libbitflags-69448112f0ca8232.rlib --extern enum_primitive=/tmp/ocl/examples/images2/target/debug/deps/libenum_primitive-2dc0d7f5a40461af.rlib --extern num=/tmp/ocl/examples/images2/target/debug/deps/libnum-151887b02ba81fd7.rlib --extern libc=/tmp/ocl/examples/images2/target/debug/deps/liblibc-d796205b80e22c45.rlib --cap-lints allow`
/home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs:51:1: 51:35 warning: `pub extern crate` does not work as expected and should not be used. Likely to become an error. Prefer `extern crate` and `pub use`.
/home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs:51 pub extern crate ocl_core as core;
                                                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs:56:9: 56:18 error: unresolved import `core::ffi`. There is no `ffi` in `core` [E0432]
/home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs:56 pub use core::ffi;
                                                                                                ^~~~~~~~~
/home/bernhard/.cargo/registry/src/github.com-88ac128001ac3a9a/ocl-0.11.0/src/lib.rs:56:9: 56:18 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `ocl`.

My rustc is rustc 1.7.0 (a5d1e7a59 2016-02-29)

Windows ABI

Intel OpenCL SDK provides headers with the stdcall calling convention under Windows. Your bindings uses extern "C" unconditionally, though.

#if defined(_WIN32)
    #define CL_API_ENTRY
    #define CL_API_CALL     __stdcall
    #define CL_CALLBACK     __stdcall
...
/* Platform API */
extern CL_API_ENTRY cl_int CL_API_CALL
clGetPlatformIDs(cl_uint          /* num_entries */,
                 cl_platform_id * /* platforms */,
                 cl_uint *        /* num_platforms */) CL_API_SUFFIX__VERSION_1_0;

Creating kernel panics on Mac OS X

Dear all,
I tried running the "trivial.rs" example on my Mac (OS X 10.11, pre-installed OpenCL 1.2, ocl version 0.13.0) put it panics when creating the kernel because Kernel::new("add", &program) returns Err([NONE]). It does this in the versions in main(), main_explained(), and main_exploded(), but interestingly NOT in main_cored() which uses ocl-core...

In main_cored I also added a call to core::get_kernel_info(&kernel, KernelInfo::NumArgs) immediately after creating the kernel (because that's what the other non-working examples do behind the scenes) but that's working fine.

I tested this using both the CPU and GPU devices in the platform, both do not work. Interestingly, when using just the GPU device and printing that one out using println!("Device: {:?}", device); I get the following suspiciously looking output:

Device: Device { Type: DEVICE_TYPE_GPU, VendorId: 16925952, MaxComputeUnits: 48, MaxWorkItemDimensions: 3, MaxWorkGroupSize: 256, MaxWorkItemSizes: [256, 256, 256], PreferredVectorWidthChar: 1, PreferredVectorWidthShort: 1, PreferredVectorWidthInt: 1, PreferredVectorWidthLong: 1, PreferredVectorWidthFloat: 1, PreferredVectorWidthDouble: 0, MaxClockFrequency: 1050, AddressBits: 64, MaxReadImageArgs: 128, MaxWriteImageArgs: 8, MaxMemAllocSize: 402653184, Image2dMaxWidth: 16384, Image2dMaxHeight: 16384, Image3dMaxWidth: 2048, Image3dMaxHeight: 2048, Image3dMaxDepth: 2048, ImageSupport: true, MaxParameterSize: 1024, MaxSamplers: 16, MemBaseAddrAlign: 1024, MinDataTypeAlignSize: 128, SingleFpConfig: FP_INF_NAN | FP_ROUND_TO_NEAREST | FP_ROUND_TO_ZERO | FP_ROUND_TO_INF | FP_FMA | FP_CORRECTLY_ROUNDED_DIVIDE_SQRT, GlobalMemCacheType: None, GlobalMemCachelineSize: 0, GlobalMemCacheSize: 0, GlobalMemSize: 1610612736, MaxConstantBufferSize: 65536, MaxConstantArgs: 8, LocalMemType: Local, LocalMemSize: 65536, ErrorCorrectionSupport: false, ProfilingTimerResolution: 80, EndianLittle: true, Available: true, CompilerAvailable: true, ExecutionCapabilities: EXEC_KERNEL, QueueProperties: QUEUE_PROFILING_ENABLE, Name: Intel(R) Iris(TM) Graphics 6100, Vendor: Intel Inc., DriverVersion: 1.2(Feb 17 2017 12:40:05), Profile: FULL_PROFILE, Version: OpenCL 1.2 , Extensions: cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_image2d_from_buffer cl_khr_gl_depth_images cl_khr_depth_images cl_khr_3d_image_writes , Platform: PlatformId(0x7fff0000), DoubleFpConfig: , HalfFpConfig: 

################################ OPENCL ERROR ############################### 

Error executing function: clGetDeviceInfo  

Status error code: CL_INVALID_OPERATION (-59)  

Please visit the following url for more information: 

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetDeviceInfo.html#errors  

############################################################################# 
, PreferredVectorWidthHalf: 0, HostUnifiedMemory: true, NativeVectorWidthChar: 1, NativeVectorWidthShort: 1, NativeVectorWidthInt: 1, NativeVectorWidthLong: 1, NativeVectorWidthFloat: 1, NativeVectorWidthDouble: 0, NativeVectorWidthHalf: 0, OpenclCVersion: OpenCL C 1.2 , LinkerAvailable: true, BuiltInKernels: , ImageMaxBufferSize: 25165824, ImageMaxArraySize: 2048, ParentDevice: None, PartitionMaxSubDevices: 0, PartitionProperties: [], PartitionAffinityDomain: , PartitionType: [], ReferenceCount: 1, PreferredInteropUserSync: true, PrintfBufferSize: 1048576, ImagePitchAlignment: 32, ImageBaseAddressAlignment: 4 }

Please let me know if you need further information (like the output of clinfo command) or if there is anything else I could try!

Thank you very much!
Michael

Looking for more details about actual project scope

Hey. Just wondering, what's an actual project scope and purpose you have? That would be great to know (or have a strict explanation) the main difference between this project and https://github.com/luqmana/rust-opencl.

Split out `core` and `ffi` modules

Tracking issue for the breakup of this repo into three pieces.

This will remain the repo for the standard types (the highest level interfaces).

Working Branch:

https://github.com/cogciprocate/ocl/tree/remove_core_ffi

New Repos:

cl-sys (crates.io)
ocl-core (crates.io)

• Move out ffi (easy)
  • Docs
  • Publish
• Move out core
  • Docs
  • Publish
• Clean up main repo (this one)
  • Docs

Docs are kill

http://doc.cogciprocate.com/ocl/ocl/ -> https://www.dynu.com/Support/Offline?domainName=cogciprocate.com&Hostname=doc.cogciprocate.com

GitHub Pages? With #21?

get_supported_image_formats fails on Mac OS X

core::get_supported_image_formats fails on OSX by returning

Image Formats: Err(
    Error converting to 'ImageChannelOrder'.
).

The reason is that some of the returned values for channel order and datatype are completely weird. On the CPU device I get:

Found 28 image formats
...
Ch.order: 4284, data type: 4317
Ch.order: 4277, data type: 268435464
Ch.order: 4277, data type: 4312
...
Ch.order: 4284, data type: 4307
Ch.order: 268435462, data type: 4306
Ch.order: 4273, data type: 4306
Ch.order: 4279, data type: 4306
Ch.order: 268435463, data type: 4306
Ch.order: 4278, data type: 4306
...

On the GPU device:

Found 84 image formats
...
Ch.order: 4279, data type: 4306
Ch.order: 268435474, data type: 4306
Ch.order: 4272, data type: 4304
...

The values were determined using this small C program (posting it here because maybe I made a mistake somewhere?)

#include <stdio.h>
#include <sys/types.h>

#include <OpenCL/cl.h>

#define CHECK_ERR { \
    if(err < 0) { \
        perror("OPenCL error"); \
        exit(1); \
    } \
}

int main() {
    cl_int err;

    cl_platform_id platform;
    err = clGetPlatformIDs(1, &platform, NULL);
    CHECK_ERR

    cl_device_id device;
    err = clGetDeviceIDs(platform, CL_DEVICE_TYPE_CPU, 1, &device, NULL);
    CHECK_ERR

    cl_context context;
    context = clCreateContext(NULL, 1, &device, NULL, NULL, &err);
    CHECK_ERR

    cl_uint num_img_formats = 0;
    cl_image_format formats[100];
    err = clGetSupportedImageFormats(context,
                                     CL_MEM_READ_WRITE,
                                     CL_MEM_OBJECT_IMAGE2D,
                                     sizeof(formats) / sizeof(formats[0]),
                                     formats,
                                     &num_img_formats);
    CHECK_ERR

    printf("Found %d image formats\n", num_img_formats);

    for (int i=0; i<num_img_formats; ++i) {
        printf("Ch.order: %d, data type: %d\n",
               formats[i].image_channel_order,
               formats[i].image_channel_data_type);
    }

    clReleaseContext(context);
}

Doing the same thing using cl-sys yields the same results.

I could not find any of those strange values in Apple's OpenCL headers.

Info example can segfault on OpenCL 1.1 hardware

Stack trace from gdb:

Platform { Profile: FULL_PROFILE, Version: OpenCL 1.1 CUDA 6.5.51, Name: NVIDIA CUDA, Vendor: NVIDIA Corporation, Extensions: cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts  } { Total Device Count: 1 }
Device (terse) { Name: GeForce 9800 GT, Vendor: NVIDIA Corporation }

Thread 1 "info" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) info stack
#0  0x0000000000000000 in ?? ()
#1  0x000055555556c6c4 in info::core::functions::enqueue_fill_buffer<f32> (
    command_queue=0x7fffffffcba0, buffer=0x7fffffffcb90, pattern=0, offset=0, 
    len=2048, wait_list=..., new_event=...) at src/core/functions.rs:2003
#2  0x00005555555693fd in info::standard::buffer::{{impl}}::enq (self=...)
    at src/standard/buffer.rs:439
#3  0x000055555556620e in info::standard::buffer::{{impl}}::new<&[usize; 1]> (
    queue=0x7fffffffdd48, flags=..., dims=0x7fffffffe068, data=...)
    at src/standard/buffer.rs:497
#4  0x0000555555561d04 in info::main () at examples/info.rs:59
#5  0x00005555556044c5 in std::sys_common::unwind::try::try_fn::h09ba69fd13531e58 ()
#6  0x000055555560164c in __rust_try ()
#7  0x0000555555603f0c in std::rt::lang_start::h5b0863080165c75e ()
#8  0x000055555557726a in main () at ../src/libcore/clone.rs:91

Clean up and consolidate error handling.

Determine exactly which errors should continue to panic and which errors need to be reported (via one of the custom error types).

Also need to finish add the custom result type, etc.

Why not using travis (or another) ?

Why not using travis to call cargo build, cargo test for each commit ?
Each pull request/commit can update the documentation...
I already use it on some of my rust libraries, so I can help you for that (I think) 😄

Cargo update because of hard coded paths in the examples

So recently I got this weird error from cargo:

alex@botev-ThinkPad-T440:~/work/metadiff/gir$ cargo update
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/cogciprocate/ocl/`
error: failed to load source for a dependency on `ocl`

Caused by:
  Unable to update https://github.com/cogciprocate/ocl/

Caused by:
  Could not find `Cargo.toml` in `/home/nick/src/github.com/cogciprocate/ocl-core`

The only place I found this path being hard coded is in the examples directory files, but it brakes my builds which work with the github head. Could you remove those?

Kernels - `Clone`, `Send`, and segfaults

Kernel includes features that a raw OpenCL kernel does not, including:

1. Type-checked arguments (not just size-checked)
2. Named arguments (with a &'static str name)
3. Prevention of a potential (difficult to debug) segfault if a buffer or
   image used by a kernel is dropped prematurely.
4. Stored defaults for the:
   • Queue
   • Global Work Offset
   • Global Work Size
   • Local Work Size

Clone, Send, and segfaults

Every struct field of the Kernel struct itself is safe to Send and Clone with the exception of mem_args. In order to keep references to buffers/images alive throughout the life of the kernel and prevent nasty, platform-dependent, and very hard to debug segfaults, storing each MemCore (buffer/image) is necessary. However, storing them means that there are compromises in other areas. The following are the options as I see them:

1. [CURRENT] Store buffers/images in an Rc<RefCell<_>>. This allows us to
   Clone but not to Send between threads.
2. Store buffers/images in an Arc<Mutex/RwLock> allowing both Clone and
   Send at the cost of performance (could add up if users constantly
   change arguments).
3. [PREVIOUS] Disallow cloning and sending.
4. Don't store buffer/image references and let them segfault if the user
   doesn't keep them alive properly.

Please provide feedback if you have thoughts, suggestions, or alternative ideas.

Colorify under Windows

… is not works, of course:

Looping through avaliable platforms (3):
←[34mPlatform { Profile: FULL_PROFILE ,

It would be better do not use terminal colors in examples. Or patch colorify for Windows support, idk.

More Dimensions

I noticed that SpatialDims only goes up to 3 dimensions. Is this a limitation in OpenCL or in these specific bindings? Could this be extended to 4?

Expose clCreateProgramWithIL functionality

I'd like to be able to use SPIR-V modules :)

Implement data sharing with OpenGL/DirectX/etc.

Collaboration thread containing notes and conversation pertaining to implementation of data sharing between OpenCL and OpenGL/DirectX/etc.

Profiling events on Mac OS X

get_event_profiling_info in ocl-core currently returns an OpenCL error on OSX. I did some investigation on this and found out that the reason is the first call to ffi::clGetEventProfilingInfo in get_event_profiling_info which is used to determine the size of the requested profiling information. More precisely, the parameter param_value_size (third argument) is set to 0 as size_t here which does not work on OSX (even using the OpenCL C API). Instead, one needs to pass something that is at least as big as the requested information, so in this case any number >= 8 will do as the returned timestamps are all 64 bits.

I suggest changing that argument from 0 as size_t to something like if cfg!(target_os="macos") { size_t::max_value() } else { 0 }. (could also just use 8 instead of size_t::max_value() but in case future OpenCL versions specify new profiling information larger than 8 bytes it would then fail again)

I'm not sure why the behavior here is different than it is on other platforms, probably just a slightly different interpretation of the OpenCL specs by Apple, which says in chapter 5.12:

param_value_size is used to specify the size in bytes of memory pointed to by param_value. This size must be >= size of return type as described in table 5.19.

Accessing SubBuffers

So this might be a very basic question as I'm new to OpenCL and thus working out this in Rust is even more challenging. Essentially I want to allocate a very large buffer of memory in the OpenCL context and be able to look only at specific parts for specific kernels (e.g. to have my own memory manager). I've saw that the standard OpenCL has SubBuffers. Would it be possible to add at some point an example of how this would look in Rust?
Thanks!

unwrap() unnecessary on Device and Platform in example code

Code in examples directory use unwrap() on variables of type Device and Platform. This is unnecessary and code doesn't compile.

For Eg:
at line 40 of info.rs

let devices = Device::list_all(platform).unwrap();

Buffer creation fails with CL_INVALID_HOST_PTR(-37) when supplied with data

The following code fails at the spots mentioned in comment. Looks like supplying some data while creating buffers crashes the program.

use std;
use ocl;

#[test]
pub fn test_buffer() {
    let src: &str = r#"
    __kernel void multiply(__global float* buffer, float coeff) {
        buffer[get_global_id(0)] *= coeff;
    }
    "#;
    let platform_id = 1; // use Intel platform
    let device_id = 0; // Use the first available device
    let platform = ocl::Platform::list()[platform_id];
    let device = ocl::Device::list_all(&platform).unwrap()[device_id];

    println!("************************************************");
    println!("Platform: {}", platform.name());
    println!("Device: {}", device.name());
    println!("************************************************");
    let context = ocl::Context::builder()
        .platform(platform)
        .devices(device)
        .build()
        .unwrap();
    let queue = ocl::Queue::new(&context, device).unwrap();
    let program = ocl::Program::builder()
        .src(src)
        .devices(device)
        .build(&context)
        .expect("OpenCL program couldn't be built");

    // Commence test with different valid kinds of buffer creation

    // Works fine
    let in_buff_0: ocl::Buffer<f32> =
        ocl::Buffer::new(&queue, Some(ocl::core::MEM_READ_WRITE), &[20], None).expect("in_buff_0");

    // First trouble
    let mut in_data_1: Vec<f32> = vec![0f32, 1.0, 2.0, 3.0];
    let dims_data_1 = [in_data_1.len()];
    let in_buff_1 = ocl::Buffer::new(&queue.clone(),
                                     Some(ocl::core::MEM_READ_WRITE),
                                     &dims_data_1,
                                     Some(&in_data_1.as_slice()));
    match in_buff_1 {
        Ok(_) => println!("Creation of in_buff_1 successful"),
        Err(e) => println!("Creation of in_buff_1 failed with {}", e),
    }

    // Second trouble
    let mut in_data_2: [f64; 2] = [0f64, 2f64];
    let dims_data_2 = [in_data_2.len()];
    let in_buff_2 = ocl::Buffer::new(&queue.clone(),
                                     Some(ocl::core::MEM_READ_WRITE),
                                     &dims_data_2,
                                     Some(&in_data_2));
    match in_buff_2 {
        Ok(_) => println!("Creation of in_buff_2 successful"),
        Err(e) => println!("Creation of in_buff_2 failed with {}", e),
    }

    // Third trouble
    let mut in_data_3: Vec<i32> = vec![0i32, 1, 2, 4, 5, 19];
    let dims_data_3 = [in_data_3.len()];
    let in_buff_3 = ocl::Buffer::new(&queue.clone(),
                                     Some(ocl::core::MEM_READ_WRITE),
                                     &dims_data_3,
                                     Some(&in_data_3));
    match in_buff_3 {
        Ok(_) => println!("Creation of in_buff_3 successful"),
        Err(e) => println!("Creation of in_buff_3 failed with {}", e),
    }
}

I tested with Intel platform and I ran it as a test using cargo test -- --nocapture. Here is the output

running 1 test
************************************************
Platform: Intel(R) OpenCL
Device:       Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz
************************************************
Creation of in_buff_1 failed with 

################################ OPENCL ERROR ############################### 

Error executing function: clCreateBuffer  

Status error code: CL_INVALID_HOST_PTR (-37)  

Please visit the following url for more information: 

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clCreateBuffer.html#errors  

############################################################################# 

Creation of in_buff_2 failed with 

################################ OPENCL ERROR ############################### 

Error executing function: clCreateBuffer  

Status error code: CL_INVALID_HOST_PTR (-37)  

Please visit the following url for more information: 

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clCreateBuffer.html#errors  

############################################################################# 

Creation of in_buff_3 failed with 

################################ OPENCL ERROR ############################### 

Error executing function: clCreateBuffer  

Status error code: CL_INVALID_HOST_PTR (-37)  

Please visit the following url for more information: 

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clCreateBuffer.html#errors  

############################################################################# 

test test_buffer::test_buffer ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

Successful call on profiling_info on Event always returns ProfilingInfoResult::Queued type

Calling profiling_info(&self, info_kind: ProfilingInfo) -> ProfilingInfoResult on an Event always returns ProfilingInfoResult::Queued(u64) type.

Looks like the implementation of from_bytes of ProfilingInfoResult always results ProfilingInfoResultQueued type regardless of the ProfilingInfo type supplied. The relevant line number from the file is here.

Is this an expected behaviour?

Relevant code and results
I have tried this on examples/events.rs and have added profiling information. Note that I call finish after each kernel invocation. I have only added the changes here

        if PRINT_DEBUG {
            println!("Enqueuing kernel [itr:{}]...", itr);
        }
        kernel.cmd().enew(&mut kernel_event).enq().unwrap();
        ocl_pq.queue().finish();

                let last_event = kernel_event.last_clone().unwrap();
        match last_event.profiling_info(ocl::enums::ProfilingInfo::Start) {
            ocl::enums::ProfilingInfoResult::Start(s) => println!("Start {}", s),
            ocl::enums::ProfilingInfoResult::End(e) => println!("End {}", e),
            ocl::enums::ProfilingInfoResult::Queued(s) => println!("Queued {}", s),
            ocl::enums::ProfilingInfoResult::Submit(sb) => println!("Submit {}", sb),
            ocl::enums::ProfilingInfoResult::Error(er) => println!("Error {}", er),
        }

        match last_event.profiling_info(ocl::enums::ProfilingInfo::End) {
            ocl::enums::ProfilingInfoResult::Start(s) => println!("Start {}", s),
            ocl::enums::ProfilingInfoResult::End(e) => println!("End {}", e),
            ocl::enums::ProfilingInfoResult::Queued(s) => println!("Queued {}", s),
            ocl::enums::ProfilingInfoResult::Submit(sb) => println!("Submit {}", sb),
            ocl::enums::ProfilingInfoResult::Error(er) => println!("Error {}", er),
        }

        match last_event.profiling_info(ocl::enums::ProfilingInfo::Queued) {
            ocl::enums::ProfilingInfoResult::Start(s) => println!("Start {}", s),
            ocl::enums::ProfilingInfoResult::End(e) => println!("End {}", e),
            ocl::enums::ProfilingInfoResult::Queued(s) => println!("Queued {}", s),
            ocl::enums::ProfilingInfoResult::Submit(sb) => println!("Submit {}", sb),
            ocl::enums::ProfilingInfoResult::Error(er) => println!("Error {}", er),
        }

        match last_event.profiling_info(ocl::enums::ProfilingInfo::Submit) {
            ocl::enums::ProfilingInfoResult::Start(s) => println!("Start {}", s),
            ocl::enums::ProfilingInfoResult::End(e) => println!("End {}", e),
            ocl::enums::ProfilingInfoResult::Queued(s) => println!("Queued {}", s),
            ocl::enums::ProfilingInfoResult::Submit(sb) => println!("Submit {}", sb),
            ocl::enums::ProfilingInfoResult::Error(er) => println!("Error {}", er),
        }

The output is

$ cargo run
Enqueuing kernel [itr:0]...
Queued 1474101516056870912
Queued 1474101519915162112
Queued 1474101516056858112
Queued 1474101516056870912
Enqueuing read buffer [itr:0]...
Setting callback (verify_result, buncha_stuff[0]) [i:0]...
Enqueuing kernel [itr:1]...
Queued 1474101519915579904
Queued 1474101523754866944
Queued 1474101519915577088
Queued 1474101519915579904
Enqueuing read buffer [itr:1]...
Setting callback (verify_result, buncha_stuff[1]) [i:1]...
# Omitting repeated results

CL_INVALID_DEVICE on OSX

This is from commit 015d995, on a MacBook Air from last year. I imagine it's related to the fact that the device_check example locks up on the GPU check?

cargo run --example info
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
    Running `target/debug/examples/info`
Looping through avaliable platforms (1):
Platform { Profile: FULL_PROFILE, Version: OpenCL 1.2 (Nov  1 2016 21:34:57), Name: Apple, Vendor: Apple, Extensions: cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event } { Total Device Count: 2 }
Device (terse) { Name: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz, Vendor: Intel }
Device (terse) { Name: Intel(R) Iris(TM) Graphics 6100, Vendor: Intel Inc. }
Context { ReferenceCount: 8, Devices: [DeviceId(0x1024500), DeviceId(0xffffffff)], Properties: ContextProperties({Platform: Platform(PlatformId(0x7fff0000))}), NumDevices: 2 }
Queue { Context: Context(0x7fcaa04038f0), Device: DeviceId(0xffffffff), ReferenceCount: 6, Properties: QUEUE_PROFILING_ENABLE }
Buffer Mem { Type: Buffer, Flags: MEM_READ_WRITE, Size: 8192, HostPtr: no mem info available, MapCount: 0, ReferenceCount: 2, Context: Context(0x7fcaa04038f0), AssociatedMemobject: None, Offset: 0 }
Image { ElementSize: 4, RowPitch: 8192, SlicePitch: 0, Width: 2048, Height: 0, Depth: 0, ArraySize: 0, Buffer: None, NumMipLevels: 0, NumSamples: 0 } Mem { Type: Image1d, Flags: MEM_READ_WRITE, Size: 8192, HostPtr: no mem info available, MapCount: 0, ReferenceCount: 1, Context: Context(0x7fcaa04038f0), AssociatedMemobject: None, Offset: 0 }
Sampler { ReferenceCount: 1, Context: Context(0x7fcaa04038f0), NormalizedCoords: false, AddressingMode: None, FilterMode: Nearest }
Program (terse) { KernelNames: 'multiply', NumDevices: 2, ReferenceCount: 2, Context: Context(0x7fcaa04038f0) }
Kernel { FunctionName: multiply, ReferenceCount: 1, Context: Context(0x7fcaa04038f0), Program: Program(0x7fcaa0700960), Attributes:  } WorkGroup { WorkGroupSize:

################################ OPENCL ERROR ###############################

Error executing function: clGetKernelWorkGroupInfo

Status error code: CL_INVALID_DEVICE (-33)

Please visit the following url for more information:

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelWorkGroupInfo.html#errors

#############################################################################
, CompileWorkGroupSize:

################################ OPENCL ERROR ###############################

Error executing function: clGetKernelWorkGroupInfo

Status error code: CL_INVALID_DEVICE (-33)

Please visit the following url for more information:

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelWorkGroupInfo.html#errors

#############################################################################
, LocalMemSize:

################################ OPENCL ERROR ###############################

Error executing function: clGetKernelWorkGroupInfo

Status error code: CL_INVALID_DEVICE (-33)

Please visit the following url for more information:

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelWorkGroupInfo.html#errors

#############################################################################
, PreferredWorkGroupSizeMultiple:

################################ OPENCL ERROR ###############################

Error executing function: clGetKernelWorkGroupInfo

Status error code: CL_INVALID_DEVICE (-33)

Please visit the following url for more information:

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelWorkGroupInfo.html#errors

#############################################################################
, PrivateMemSize:

################################ OPENCL ERROR ###############################

Error executing function: clGetKernelWorkGroupInfo

Status error code: CL_INVALID_DEVICE (-33)

Please visit the following url for more information:

https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelWorkGroupInfo.html#errors

#############################################################################
 }WorkGroup { WorkGroupSize: 128, CompileWorkGroupSize: [0, 0, 0], LocalMemSize: 0, PreferredWorkGroupSizeMultiple: 1, PrivateMemSize: 0 }
EventList { inner: Array(EventArray { array: [Event(Event(0x7fcaa0403e10)), Event(Event(0x0)), Event(Event(0x0)), Event(Event(0x0)), Event(Event(0x0)), Event(Event(0x0)), Event(Event(0x0)), Event(Event(0x0))], len: 1 }) }
Event { CommandQueue: CommandQueue(0x7fcaa0700400), CommandType: WriteBuffer, ReferenceCount: 1, CommandExecutionStatus: Complete, Context: Context(0x7fcaa04038f0) }

bool isn't `OclPrm`

Why not unwrapping Mem dropping ?

https://github.com/cogciprocate/ocl/blob/master/src/core/types/abs.rs#L344

.ok() method doesn't panic in any case, but is it important ?

Create build script that accommodates Windows-MSVC

Should be a simple matter to link to the appropriate ICD loader, OpenCL.lib, in addition to handling GNU builds (dll), etc.

Panic when no GPUs

It seems that

let devices = ocl::Device::list(&*OCL_PLATFORM, Some(ocl::core::DEVICE_TYPE_GPU));

will panic if there isn't any GPUs. I was expecting an empty Vec instead. Is this intended behavior?

Intel Iris Pro - OS X driver bug

As mentioned in #9, the events example panics (on OS X with an Intel Iris Pro GPU, in this case). Here's the output:

Enqueuing kernel [itr:0]...
Enqueuing read buffer [itr:0]...
Setting callback (verify_result, buncha_stuff[0]) [i:0]...
Enqueuing kernel [itr:1]...
Enqueuing read buffer [itr:1]...

Event: `0x7fadd33004d0` has completed with status: `0`, data_set_size: '262144`, addend: 11, itr: `0`.
correct_result: 448, result_vec[0]:448
correct_result: 18, result_vec[1]:18
correct_result: 261, result_vec[2]:261
correct_result: 213, result_vec[3]:213
correct_result: 488, result_vec[4]:488
Setting callback (verify_result, buncha_stuff[1]) [i:1]...
Enqueuing kernel [itr:2]...

Event: `0x7fadd0d0a3b0` has completed with status: `0`, data_set_size: '262144`, addend: 11, itr: `1`.
correct_result: 459, result_vec[0]:459
correct_result: 29, result_vec[1]:29
correct_result: 272, result_vec[2]:272
correct_result: 224, result_vec[3]:224
correct_result: 499, result_vec[4]:499
Enqueuing read buffer [itr:2]...
thread '<unnamed>' panicked at 'assertion failed: `(left == right)` (left: `317`, right: `306`)', examples/events.rs:52
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Setting callback (verify_result, buncha_stuff[2]) [i:2]...
thread '<unnamed>' panicked at 'assertion failed: `(left == right)` (left: `265`, right: `254`)', libc++abi.dylib: examples/events.rs:52
terminating with uncaught foreign exceptionEnqueuing kernel [itr:3]...


Event: `0x7fadd33008d0` has completed with status: `0`, data_set_size: '262144`, addend: 11, itr: `2`.
libc++abi.dylib: %

Implement a safe mapped memory wrapper

... to handle any host memory mapped to a buffer or image object on the device.

The enqueue_map... functions are currently returning pointers and leaving it completely to the caller. It's also currently possible to map some memory by setting the right flags when creating a buffer or image. Doing this just leaves everything in the hands of the caller (should probably error if either of the mapping CL_MEM_ flags are on to prevent this for now -- or at least provide something else in the way of warnings as it's not marked unsafe to create either mem object).

This new type should automatically track any pending reads and writes as well as ensure that all commands related to it have completed before unmapping and dropping.