OpenCL, Vulkan, Sycl

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

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

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

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

Потому что Khronos Group любит вводящие в заблуждение маркетинговые сообщения.

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

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

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

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

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

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

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

От Группы Хронос:

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

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

Как OpenCL соотносится с vulkan?

Оба они могут конвейерно отделять работу от хоста к графическому процессору и от графического процессора к хосту, используя очереди, чтобы уменьшить накладные расходы связи с использованием нескольких потоков. Directx-opengl не может?

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

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

если в opencl был vulkan, то он был скрыт от публики в течение 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

ниже приведены также трассировщики лучей и примеры обработки изображений.

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

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

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

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

При той же цене графические процессоры AMD могут выполнять вычисления на opencl быстрее, а Intel igpus с той же вычислительной мощностью потребляет меньше энергии. (изменить: кроме случаев, когда алгоритмы чувствительны к производительности кеша, когда Nvidia имеет преимущество)

Кроме того, я написал ядро ​​SGEMM opencl и запустил на HD7870 со скоростью 1,1 Тфлопс, проверил Интернет, а затем увидел метку SGEMM на GTX680 для такой же производительности с использованием популярного названия на CUDA! (Соотношение цены gtx680 / hd7870 было 2). (редактировать: cc3.0 от Nvidia не использует кеш L1 при чтении глобальных массивов, а мое ядро ​​было чисто локальной / общей памятью + некоторые регистры «выложены плиткой»)

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

Здесь,

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

говорит

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

Реализация резервного ЦП поддается отладке!

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

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

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

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

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