python — впереди время на GPU

Я пытаюсь использовать OpenCL в качестве цели для моей предварительной компиляции. В моем ядре Halide у меня есть 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 и, если да, есть идеи, в чем может быть проблема?

Благодарю.

1

Решение

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

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

1

Другие решения

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

0

По вопросам рекламы [email protected]