Java может использовать драйвер OpenCL.
Чуть выше давали ссылку на java-обертку для OpenCL API.
Насколько я понимаю, это не освобождает от написания kernel на С-подобном языке, а оборачивает только вызовы OpenCL API, описанные в статье.
Не конфликтуют именно драйверы OpenCL? Ну то есть то, что карты разных производителей в одной системе работать могут это факт известный, а вот как там с использованием OpenCL при этом? Хотя по идее должны работать… ведь для того все и задумывалось)
Если будете проводить тесты — напишите пожалуйста, что из этого вышло — очень интересно)
Уже почти так и есть. Новая архитектура Nbidia Fermi (которая в железе пока в числе 7 уникальных чипов существует) была анонсирована как отлично подходящая под вычисления.
Позже рекламщики Nvidia срочно бросились исправлять перегибы и рассказывать, что для 3D графики архитектура тоже очень подходит и покупать ее для игр тоже имеет смысл.
Число регистров итп. для конкретной карты Nvidia можно посмотреть в Nvidia OpenCL Programming Guide (Appendix A) — на него есть ссылка в статье.
Там написано какая карта имеет какую версию Compute Capability, там же и расшифровка, что в себя включает каждая версия Compute Capability.
можно было бы, например, сравнить производительность драйверов OpenCL Nvidia и AMD. При примерно равных условиях: какой-нибудь простой пример из SDK запустить с одинаковыми global size и work-group size и посмотреть что быстрее… ну это из совсем тривиального…
Только сдается мне одновременно они не заработают — конфликтовать драйверы начнут друг с другом. Хотя это только догадки, конечно.
Работает, я надеюсь, все же одинаково. В целом.
Но ведь на производительность сильно влияет конкретная архитектура устройства. И вот тут уже могут вылезти особенности и даже ошибки.
Пример: на моей видеокарте NVidia 8192 регистра, то есть если задать размер группы 512 элементов (максимум для моей видеокарты), то на каждый из них по 16 регистров. Если 16 регистров недостаточно для выполнения kernel — полетит ошибка во время исполенния kernel.
То есть если ужать kernel в 16 регистров не выйдет — прийдется задействовать карту не на полную мощьность.
Для чипов AMD, возможно, такое ограничение будет более сильное или слабое, а может его и вовсе не будет, все зависит от архитектуры.
Такие вещи специфичны для конкретного устройства и знание некоторых может помочь ускорить работу приложения, а, иногда, и сберечь нервы)
Поддержка в Visual Studio примерно такая жа как и для CUDA: скопировать файл подсветки синтаксиса, прописать пути до библиотек и заголовочных файлов. И все)
Компилятор встроен в платформу, поэтому даже custom build step не нужен.
Постараюсь как можно быстрее закончить работу над статьями, я и не думал что этот вопрос вызовет такой интерес.
Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя.
То есть чтобы использовать особенности архитектуры ускорителей AMD разработчик не должен учиться пользоваться Brook+, а должен изучить особенности архитектуры этих ускорителей (без этого-то совсем никуда) и написать OpenCL приложение так, чтобы оно использовало все доступные возможности.
Точно так же как MKL (математическая библиотека Intel) использует по максимуму возможности процессоров Intel, а ACML — аналог AMD — использует особенности процессоров AMD, хотя написаны обе они, вероятно, на С++
Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня
Вот тут я написал, что в этом плане CUDA и OpenCL одинаковы.
В вашем понимании засело то, что те действия, которые CUDA выполнялись руками в OpenCL за Вас будет делать кто-то (а именно, компилятор) — это не так. Точно так же будете решать что в какой памяти располагать итд., полностью сами будете решать.
OpenCL не предоставляет какой-то более высокий уровень абстракции, на котором все (или многое) будет делаться за программиста, нет, не будет. OpenCL ничего не оптимизирует (точнее компилятор оптимизирует кое-что, но не более чем nvcc в CUDA)
Я сейчас пишу статью, в которой постараюсь все подробно объяснить, точнее похоже выйдет даже две — одна вгубь спецификаций OpenCL, другая больше практическая — что и как писать.
Дело в том, что как язык — CUDA — это расширени С. Так же как OpenCL, в этом они схожи очень сильно, ведь Вы не пишите CUDA-приложения на ассемблерном коде GPU, за Вас это делает nvcc — специальный компилятор, а Вы решаете сколько хотите использовать ресурсов, как доступаться к памяти, в какой памяти размещать данные. Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня.
C этим согласен, специфичные вещи легче внедрять в CUDA и тем самым обеспечивать интерес к платформе.
Хотя вот есть же в Microsoft Visual C++ не описанные стандартом вещи, ну, скажем, __TRY / __CATCH / __FINALLY (кажется не напутал с количество подчеркиваний).
В принципе тут ситуация могла бы развиваться по такому же пути… Не возьмусь судить, что лучше и, тем более, как оно будет в действительности, но возможность ведь есть?
Ну уровень абстракции в OpenCL в общем-то не отличается от CUDA практически.
Ведь OpenCL, как было упомянуто в статье, работает поверх CUDA Driver API (в случае NVidia) как и CUDA. А он, в свою очередь, работает с ускорителем, поэтому производительность OpenCL приложений может сравняться с CUDA.
Дело в том, что у меня нет в наличии нет двух устройств с поддержкой OpenCL чтобы протестировать это в текущей реализации NVidia
Но в общем да, использование нескольких ускорителей предполагается.
В скором времени я напишу подробную статью о том как строится OpenCL приложение.
В кратце так: из кода программы Вы можете получить число устройств с поддержкой OpenCL и их характеристики, потом выбрать и проинициализировать нужное устройство (или несколько устройств) и далее работать с ним.
Вы правы, на хабре даже статья по это проскакивала небольшая.
Видимо сотрудничество с Bullet и ознаменует конец дружбы с Havok (и, возможно, виной тому как раз покупка Havok конкурентом AMD — Intel)
Чуть выше давали ссылку на java-обертку для OpenCL API.
Насколько я понимаю, это не освобождает от написания kernel на С-подобном языке, а оборачивает только вызовы OpenCL API, описанные в статье.
Если будете проводить тесты — напишите пожалуйста, что из этого вышло — очень интересно)
С++ kernel'ы в CUDA?
Позже рекламщики Nvidia срочно бросились исправлять перегибы и рассказывать, что для 3D графики архитектура тоже очень подходит и покупать ее для игр тоже имеет смысл.
Там написано какая карта имеет какую версию Compute Capability, там же и расшифровка, что в себя включает каждая версия Compute Capability.
Только сдается мне одновременно они не заработают — конфликтовать драйверы начнут друг с другом. Хотя это только догадки, конечно.
Но ведь на производительность сильно влияет конкретная архитектура устройства. И вот тут уже могут вылезти особенности и даже ошибки.
Пример: на моей видеокарте NVidia 8192 регистра, то есть если задать размер группы 512 элементов (максимум для моей видеокарты), то на каждый из них по 16 регистров. Если 16 регистров недостаточно для выполнения kernel — полетит ошибка во время исполенния kernel.
То есть если ужать kernel в 16 регистров не выйдет — прийдется задействовать карту не на полную мощьность.
Для чипов AMD, возможно, такое ограничение будет более сильное или слабое, а может его и вовсе не будет, все зависит от архитектуры.
Такие вещи специфичны для конкретного устройства и знание некоторых может помочь ускорить работу приложения, а, иногда, и сберечь нервы)
На этой неделе постараюсь закончить практическую часть обзора — чтобы было проще и интереснее щупать)
Компилятор встроен в платформу, поэтому даже custom build step не нужен.
Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя.
То есть чтобы использовать особенности архитектуры ускорителей AMD разработчик не должен учиться пользоваться Brook+, а должен изучить особенности архитектуры этих ускорителей (без этого-то совсем никуда) и написать OpenCL приложение так, чтобы оно использовало все доступные возможности.
Точно так же как MKL (математическая библиотека Intel) использует по максимуму возможности процессоров Intel, а ACML — аналог AMD — использует особенности процессоров AMD, хотя написаны обе они, вероятно, на С++
Вот тут я написал, что в этом плане CUDA и OpenCL одинаковы.
В вашем понимании засело то, что те действия, которые CUDA выполнялись руками в OpenCL за Вас будет делать кто-то (а именно, компилятор) — это не так. Точно так же будете решать что в какой памяти располагать итд., полностью сами будете решать.
OpenCL не предоставляет какой-то более высокий уровень абстракции, на котором все (или многое) будет делаться за программиста, нет, не будет. OpenCL ничего не оптимизирует (точнее компилятор оптимизирует кое-что, но не более чем nvcc в CUDA)
Я сейчас пишу статью, в которой постараюсь все подробно объяснить, точнее похоже выйдет даже две — одна вгубь спецификаций OpenCL, другая больше практическая — что и как писать.
Хотя вот есть же в Microsoft Visual C++ не описанные стандартом вещи, ну, скажем, __TRY / __CATCH / __FINALLY (кажется не напутал с количество подчеркиваний).
В принципе тут ситуация могла бы развиваться по такому же пути… Не возьмусь судить, что лучше и, тем более, как оно будет в действительности, но возможность ведь есть?
Ведь OpenCL, как было упомянуто в статье, работает поверх CUDA Driver API (в случае NVidia) как и CUDA. А он, в свою очередь, работает с ускорителем, поэтому производительность OpenCL приложений может сравняться с CUDA.
А тут как раз и новая серия графических чипов — hd5000 — подоспела; все складывается как нельзя лучше.
Но в общем да, использование нескольких ускорителей предполагается.
В кратце так: из кода программы Вы можете получить число устройств с поддержкой OpenCL и их характеристики, потом выбрать и проинициализировать нужное устройство (или несколько устройств) и далее работать с ним.
Видимо сотрудничество с Bullet и ознаменует конец дружбы с Havok (и, возможно, виной тому как раз покупка Havok конкурентом AMD — Intel)