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 ускорители