Вперед времени на GPU

Question

Я пытаюсь использовать OpenCL в качестве цели для моей компиляции досрочно. В моих галогенидах ядра у меня есть Func называется norm, который я составляю так:

... 

// Start with a default target 
Target target = get_host_target(); 

// Set opencl 
target.set_feature(Target::OpenCL); 

// Compile 
std::vector<Argument> args1(2); 
args1[0] = input; 
args1[1] = n; 
norm.compile_to_file("norm", args1, target); 

, который я затем скомпилировать (и выполнить, чтобы получить norm.o и norm.h) без ошибок с использованием

g++ -o mavg kernel.cpp -I /opt/intel/intel-opencl-1.2-5.0.0.43/opencl-1.2-sdk-5.0.0.43/include -I Halide/include -L Halide/lib -lHalide -lOpenCL 

тогда у меня есть автоматически (в Python) библиотеки обертку, которая вызывает мое скомпилированные ядро:

#include <stdio.h> 
#include <CL/cl.h> 
#include <stdlib.h> 
#include "norm.h" 

#if defined(WIN32) || defined(_WIN32) || defined(__WIN32) 
    #define LIBRARY_API extern "C" __declspec(dllexport) 
#else 
    #define LIBRARY_API extern "C" 
#endif 

// Compiled with the following values 
// float* arg0 (float32) arg0 = <numpy.core._internal._ctypes object at 0x7f8b5e54a790> 
// int arg1 (<type 'int'>) arg1 = c_int(5) 
// float* arg2 (float32) arg2 = <numpy.core._internal._ctypes object at 0x7f8b5e54a690> 
// int arg0_h (<type 'int'>) arg0_h = c_int(768) 
// int arg0_w (<type 'int'>) arg0_w = c_int(1024) 
// int arg0_nd (<type 'int'>) arg0_nd = c_int(3) 
// int arg0_n (<type 'int'>) arg0_n = c_int(1) 
// int arg2_h (<type 'int'>) arg2_h = c_int(768) 
// int arg2_w (<type 'int'>) arg2_w = c_int(1024) 
// int arg2_nd (<type 'int'>) arg2_nd = c_int(3) 
// int arg2_n (<type 'int'>) arg2_n = c_int(1) 
LIBRARY_API int run(float* arg0, int arg1, 
        float* arg2, int arg0_h, int arg0_w, int arg0_nd, int arg0_n, int arg2_h, int arg2_w, int arg2_nd, int arg2_n) 
{ 
    buffer_t buf_arg0 = {0}; 
    buf_arg0.extent[0] = arg0_w; // buffer width 
    buf_arg0.extent[1] = arg0_h; // buffer height 
    buf_arg0.extent[2] = 3; // buffer depth 
    buf_arg0.stride[0] = 1; // spacing in memory between adjacent values of x 
    buf_arg0.stride[1] = arg0_w; // spacing in memory between adjacent values of y 
    buf_arg0.stride[2] = arg0_w*arg0_h; // buffer depth 
    buf_arg0.elem_size = arg0_n * sizeof(float); // bytes per element 
    buf_arg0.host = (uint8_t*) arg0; // host buffer 

    buffer_t buf_arg2 = {0}; 
    buf_arg2.extent[0] = arg2_w; // buffer width 
    buf_arg2.extent[1] = arg2_h; // buffer height 
    buf_arg2.extent[2] = 3; // buffer depth 
    buf_arg2.stride[0] = 1; // spacing in memory between adjacent values of x 
    buf_arg2.stride[1] = arg2_w; // spacing in memory between adjacent values of y 
    buf_arg2.stride[2] = arg2_w*arg2_h; // buffer depth 
    buf_arg2.elem_size = arg2_n * sizeof(float); // bytes per element 
    buf_arg2.host = (uint8_t*) arg2; // host buffer 

    norm(&buf_arg0, arg1, &buf_arg2); 
    return 0; 
} 

Я тогда получить

undefined symbol: clBuildProgram 

, когда я пытаюсь позвонить в свою библиотеку, используя ctypes в Python. Поддерживается ли OpenCL AOT-компиляция, и если да, то какая идея может быть проблемой?

Спасибо.

Answer 1

Галогенид версии я использовал устарел ... Я очистил ее, принес текущую сборку, и это теперь работает: https://github.com/halide/Halide/tree/release_2015_09_11

Для тех, кто заинтересован, у меня не было, чтобы добавить OpenCL включить или линкер флаги.

Answer 2

Мы изменили Halide, чтобы автоматически искать и динамически загружать библиотеки API графического процессора. Это произошло еще в апреле, но есть несколько исправлений ошибок через июнь или около того. Теперь больше не нужно связывать библиотеки поддержки OpenCL с исполняемым файлом с помощью Halide, хотя если символы могут быть найдены в текущем процессе без загрузки каких-либо библиотек, Halide будет их использовать. Таким образом, связывание с библиотекой - это способ избежать поиска пути.