Мобильная версияОднако нам не удалось заставить DPC++ выполнить фактическую компиляцию перед этапом компоновки. В созданном файле .so отсутствуют все ядра, и он не может быть скомпонован другим компилятором.
Ответ, найденный в этой теме от 2021 года, предполагает, что для создания окончательного двоичного файла следует использовать DPC++. :
Создайте статическую или общую библиотеку из программы sycl с помощью dpc++
Однако это нежизнеспособное предложение по нескольким причинам:
- Мы не можем требовать от наших конечных пользователей установки проприетарных пакетов компиляторов для связи с нашим кодом.
- Это делает это невозможным. распространять и обновлять общую библиотеку (наш продукт) отдельно от программ, которые ее используют (продукты наших пользователей).
- Поскольку ядра не генерируются до момента компоновки, это приводит к компиляции раз в сотни раз медленнее даже для нашего собственного программного обеспечения (сотни небольших модульных тестов и прикладных программ, которые раньше компоновались за миллисекунды, теперь каждый из них вызывает перекомпиляцию нашей огромной библиотеки, поскольку .so - это всего лишь оболочка.
Мы хотим, чтобы просто сгенерируйте фактический окончательный код (ядра хоста+устройства для выбора целей графического процессора и параллельного процессора) в общую библиотеку с API-интерфейсом только для хоста, который никоим образом не раскрывает SYCL (т. е. компоновщику не нужно знать о СИКЛ). Возможно ли создать общую библиотеку, содержащую код SYCL, но являющуюся реальной распространяемой общей библиотекой с полностью скомпилированными ядрами?
Я не могу поверить, что Khronos или Intel смогут разработать флагманскую кроссплатформенную библиотеку вычислительный стандарт будущего, который делает невозможным реализацию общих библиотек. Но ни я, ни мои коллеги не смогли найти способ заставить это работать.
Есть ли способ создать настоящие общие библиотеки с помощью SYCL? Мы уже проделали большую работу по переносу нашего кода на SYCL, прежде чем обнаружили эту кирпичную стену, и нам не хотелось бы тратить все эти усилия на отказ от SYCL и перенос всего на третью модель программирования. Но сейчас это выглядит как препятствие.
Если невозможно создать распространяемую (разделяемую или статическую) библиотеку, содержащую ядра SYCL, с помощью DPC++, но можно это сделать с помощью другая реализация, такая как AdaptiveCpp, мне тоже очень интересно узнать, как это сделать.
Большое спасибо за любую помощь, которую вы можете предложить!
Минимальный пример:
test.hh:
void hello();
normal-lib.cc:
#include "test.hh"
void hello(){ }
sycl-lib.cc:
#include
#include "test.hh"
void hello(){
sycl::queue q;
q.submit([](sycl::handler &cgh){
cgh.single_task([](){
// We don't need to do anything to trigger the failure,
// it happens as soon as any SYCL kernel is defined.
});
}).wait();
}
test-main.cc:
#include "test.hh"
int main() {
hello();
return 0;
}
Как воспроизвести:
$ icpx -fPIC -fsycl -fsycl-unnamed-lambda -c sycl-lib.cc
$ icpx -shared sycl-lib.o -o libsycl-lib.so
$ cc -shared normal-lib.o -o libnormal-lib.so
$ cc -o normal-test test-main.cc -L. -lnormal-lib
$ ./normal-test
$ # Perfect, no problem here. Normal libraries work.
$ icpx -fPIC -fsycl -c sycl-lib.cc
$ icpx -shared sycl-lib.o -o libsycl-lib.so
$ cc -o sycl-test test-main.cc -L. -lsycl-lib -lsycl
$ ./sycl-test 2>&1 | c++filt
terminate called after throwing an instance of 'sycl::_V1::runtime_error'
what(): No kernel named typeinfo name for hello()::{lambda(sycl::_V1::handler&)#1}::operator()(sycl::_V1::handler&) const::{lambda()#1} was found -46 (PI_ERROR_INVALID_KERNEL_NAME)
# Problem is here: Why was the kernel code not generated when building the shared library with "icpx -shared"?
Подробнее здесь: https://stackoverflow.com/questions/784 ... -using-dpc
