OpenCL, Vulkan, Sycl

Я пытаюсь понять экосистему OpenCL и как вулкан вступает в игру.

  • Я понимаю, что OpenCL-это фреймворк для выполнения кода для графических процессоров, а также ядер cpu, которые могут быть скомпилированы в SPIR
  • Вулкан также может использоваться в качестве вычислительного api, используя тот же язык SPIR
  • SYCL новая спецификация которая позволяет написать код opencl как свойственный стандарт соответствуя c++14. Насколько я понимаю, свободных нет. реализация этой спецификации еще не завершена.

учитывая, что:

  • Как OpenCL относится к вулкану ? Я понимаю, что OpenCL является более высоким уровнем и абстрагирует устройства ,но использует (или может ) он использует вулкан внутри? (вместо того, чтобы полагаться на драйверы конкретного поставщика)

  • Vulkan рекламируется как вычислительный и графический api, однако я нашел очень мало ресурсов для вычислительной части-почему это ?

  • Вулкан имеет преимущества производительности над OpenGL. То же самое верно для Vulkan vs OpenCl? (OpenCL печально известен тем, что медленнее, чем CUDA)

  • использует ли SYCL OpenCL внутри или может ли он использовать vulkan ? Или он не использует ни то, ни другое и вместо этого полагается на низкий уровень, специфичный для поставщика API для реализации ?

2 ответов


как OpenCL относится к вулкану ? Я понимаю, что OpenCL является более высоким уровнем и абстрагирует устройства ,но использует (или может ) он использует вулкан внутри?

они не связаны друг с другом.

ну, технически они используют один и тот же промежуточный язык шейдеров, но Вулкан запрещает модель выполнения ядра, а OpenCL запрещает модель выполнения шейдеров. Из-за этого вы не можете просто взять шейдер, предназначенный для OpenCL, и вставить его на вулкане или наоборот.

Vulkan рекламируется как вычислительный и графический api, однако я нашел очень мало ресурсов для вычислительной части-почему это ?

потому что группа Khronos любит вводить в заблуждение маркетинговые объявления.

Vulkan не более вычислительный API, чем OpenGL. Он может иметь вычислительные шейдеры, но они ограничены в функциональности. То, что вы можете сделать в вычислительной операции OpenCL, просто недоступно через OpenGL / Vulkan CS.

Vulkan CS, как и CS OpenGL, предназначены для использования в одном: для поддержки графических операций. Чтобы сделать отбраковку, создавать косвенные графические команды, манипулировать системами частиц и другие подобные вещи. CS работают с той же числовой точностью, что и графические шейдеры.

Вулкан имеет преимущества производительности над OpenGL. То же самое верно для Vulkan vs OpenCl?

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

Vulkan CS не отличаются в этом отношении. Производительность будет зависеть от зрелости водителей.

кроме того, есть тот факт, что, опять же, есть много вещей, которые вы можете сделать в вычислительной операции OpenCL, которую вы не может сделать в Вулкан CS.

использует ли SYCL OpenCL внутренне или может использовать вулкан ?

из группы Хронос:

SYCL (произносится как " серп’)-это слой абстракции без роялти, кросс-платформенный, который основывается на базовых концепциях, переносимости и эффективности OpenCL...

Так что да, он построен поверх OpenCL.


как OpenCL относится к вулкану ?

они оба трубопровода сепары работы с хоста на GPU и GPU на хост с использованием очереди, чтобы сократить расходы на связь с помощью нескольких потоков. Directx-opengl не может?

  • OpenCL: первоначальный релиз 28 августа 2009 года. Более широкая аппаратная поддержка. Указатели разрешены, но только для использования в устройстве. Можно использовать локальную память, совместно используемую потоками. Гораздо проще начать hello world. Имеет api накладные расходы для команд, если они не находятся в очереди на стороне устройства. Можно выбрать неявную синхронизацию нескольких устройств или явное управление. Ошибки в основном закреплены за 1.2, но я не знаю о версии 2.0.

  • Вулкан: первоначальный релиз 16 февраля 2016 года (но прогресс с 2014 года). Более узкая аппаратная поддержка. Может ли SPIR-V обрабатывать указатели? А может, и нет? Нет опции локальной памяти? Трудно начать Привет мир. Меньше API служебные. Можно ли выбрать неявное управление несколькими устройствами? Все еще багги для игры Dota-2 и некоторых других игр. Использование графики и вычислительного конвейера одновременно может скрыть еще большую задержку.

если в opencl был вулкан, то он был скрыт от общественности в течение 7-9 лет. Если они могли добавить его, почему они не сделали этого для opengl?(может быть, из-за давления physx/cuda?)

Vulkan рекламируется как вычислительный и графический api, однако я найдено очень мало ресурсов для вычислительной части-почему это ?

ему нужно больше времени, как и opencl.

вы можете проверить информацию о вычислительных шейдерах здесь:

https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#fundamentals-floatingpoint

вот пример системы частиц, управляемой вычислительными шейдерами:

https://github.com/SaschaWillems/Vulkan/tree/master/computeparticles

ниже этого есть raytracers и примеры обработки изображений тоже.

Вулкан имеет преимущества производительности над OpenGL. То же самое верно для Вулкан против OpenCl?

  • Vulkan не нужно синхронизировать для другого API. Его о синхронизации буферов команд между commandqueues.
  • OpenCL необходимо синхронизировать с opengl или directx (или vulkan?) перед использованием общего буфера (буферы взаимодействия cl-gl или dx-cl). Это накладные расходы, и вы должны скрывать это используя буфер обмена и конвейеризации. Если общий буфер не существует, он может работать одновременно на современном оборудовании с opengl или directx.

OpenCL печально известен тем, что медленнее, чем CUDA

Это было, но теперь его зрелые и проблемы cuda, особенно с гораздо более широкой аппаратной поддержкой от всех игровых графических процессоров до fpgas с использованием версии 2.1, например, в будущем Intel может поместить fpga в Core i3 и включить его для (soft-x86 core ip) многоядерный процессор модель, закрывающая разрыв между производительностью gpu и процессором, чтобы обновить игровой опыт cpu-physx или просто позволить реализации физики opencl сформировать его и использовать по крайней мере %90 die-area вместо эффективно используемой области %10-%20 мягкого ядра.

С такой же ценой, графические процессоры AMD могут вычислять быстрее на opencl и с такой же вычислительной мощностью Intel igpus рисовать меньше мощности.

кроме того, я написал ядро SGEMM opencl и запустил на HD7870 в 1.1 Tflops и проверил интернет, а затем увидел SGEMM henchmark на GTX680 для той же производительности, используя популярное название на CUDA!(соотношение цены gtx680/hd7870 было 2).

использует ли SYCL OpenCL внутри или может ли он использовать vulkan ? Или нет? используйте ни то, ни другое и вместо этого полагается на низкий уровень, API поставщика быть реализованным ?

здесь

https://www.khronos.org/assets/uploads/developers/library/2015-iwocl/Khronos-SYCL-May15.pdf

говорит

предоставляет методы для работы с целями, которые не имеют В OpenCL(пока!)

резервная реализация CPU отлаживается!

таким образом, он может вернуться к чистой потоковой версии(аналогичной aparapi java).

можно получить доступ к объектам OpenCL из объектов SYCL Может создавать объекты SYCL из объекта OpenCL

взаимодействие с OpenGL остается в SYCL - Использует то же самое структуры/типа

он использует opencl(возможно, не напрямую, но с обновленной связью драйверов?), он развивается параллельно opencl, но может возвращаться к потокам.

от самого маленького встроенного устройства OpenCL 1.2 до самого продвинутого В OpenCL 2.2 ускорители