2016-11-20 2 views
11

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

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

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

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

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

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

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

+1

«OpenCL печально известен тем, что он медленнее, чем CUDA». По словам кого? –

ответ

6

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

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

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

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

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

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

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

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

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

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

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

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

От Khronos Группа:

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

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

+0

Итак, в это время Vulkan не поддерживает вычислительные ядра, поэтому на нем не может быть построена не opencl или аналогичная библиотека вычислений высокого уровня? Я был чем-то вроде того, что OpenCL/Sycl может быть реализован поверх вулкана (поскольку NVIDIA, похоже, не поддерживает OpenCL 2.x) – cor3ntin

+1

@ cor3ntin: Что вы ожидаете? NVIDIA поддерживает * конкурента * для OpenCL. Почему они это поддерживают? Пока люди готовы использовать CUDA для доступа к оборудованию NVIDIA, у них нет оснований поддерживать OpenCL. –

+0

@Nicolas Bolas - OpenCL, похоже, страдает от тех же проблем OpenGL (с точки зрения поддержки поставщиков). Я надеялся, что Вулкан был универсальным ответом на это. Кроме того, SYCL кажется действительно отличным (с точки зрения разработчика C++, с точки зрения интеграции на языке C++), и мне очень грустно, что единственным исполнителем этого является несвободный продукт - и что на самом деле это не реально реализовать спецификацию, поскольку не было бы способа заставить ее работать на оборудовании NVIDIA. – cor3ntin

3

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

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

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

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

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

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

Необходимо больше времени, как и opencl.

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

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

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

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

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

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

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

OpenCL, к сожалению, печально известный к тому медленнее, чем CUDA

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

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

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

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

Здесь

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

говорит

Предоставляет методы для решения задач, которые не имеют OpenCL (пока!) Реализация

запасной вариант процессора отладке !

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

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

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

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

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

Смежные вопросы