Параллельные вычисления на GPU (2 стр)

Blew_zc
> А вот это зависит от специфических алгоритмов, заточенных под GPU. Ибо у GPU
> куча нюансов по работе с памятью, синхронизацией, etc...
> Например, у GPU нет стека. Трассировку путем рекурсивного обхода дерева влоб не
> сделаешь :)
Да. Я понимаю, что там и архитектура другая, и подход с точки зрения программирования немного отличается.

FROL
> Чушь. Бери OpenCL, он отличный.
Я читал, что на ATI он медленно работает, заметно медленней, чем на NVIDIA. Правда не знаю как сейчас с этим дела обстоят.

asvp
> Про CUDA понятно, он отпадает по п.6
> Про OpenCL непонятно почему отпала п. 5. Что CUDA, что OpenCL умеют работать
> непосредственно с ресурсами DX и OGL.
Я перепутал.. по пункту 6, а не 5. Здесь имелось ввиду:
> Я читал, что на ATI он медленно работает, заметно медленней, чем на NVIDIA. Правда не знаю как сейчас с этим дела обстоят.

asvp
> А вы можете из GLSL или HLSL создавать текстуры? Если можете научите, пож, а
> иначе этот пункт равносилен п.5.1.
Ну так можно же через GLSL рисовать в текстуру, я это имел ввиду

asvp
> А так по теме:
> Конечно все зависит от характера вычислений.
> Но если OpenCL работает медленно GLSL, значит вы не научились работать с
> OpenCL.
К сожалению, я еще не пробовал работать с OpenCL. Но судя по следующему видео https://www.youtube.com/embed/aJCcqa87ZsQ, OpenCL работает заметно медленней, чем CUDA и GLSL. Причем GLSL быстрее CUDA, опять же, судя по видео.

Andrey
> Вообще-то бред. В некоторых задачах он рвет Ncidia на CUDA. AMD очень серьезно
> взялись за OpenCL.
Опять же привожу в пример видео сравнение: https://www.youtube.com/embed/aJCcqa87ZsQ. Если у Вас есть друге сравнения, буду рад их увидеть.

Zefick
> Может потому что на ATI вообще всё медленнее, такой вариант не рассматривался?
> :-7
Нет :D

eagle
> Если OpenCL устроит boost.compute посмотрите
Посмотрю, спасибо

ialexbr
> Ну так можно же через GLSL рисовать в текстуру, я это имел ввиду
Ну тогда это относится к п.5.1
> 5.1. возможность сохранять результаты вычислений сразу в OpenGL текстуру;

> 5.2. возможность создать OpenGL текстуру из результатов вычислений, находящихся в видеопамяти;
Не актуален.

> К сожалению, я еще не пробовал работать с OpenCL.
Ну о чем тогда базар?

Один только п.6 говорит об OpenCL или GLSL.

Видео ни о чем.
Это не показатель.
- неизвестная машина.
- неизвестная видекоарта.
- неизвестная реализация алгоритмов на CUDA, OpenCL, GLSL. Вру. Можно  скачать

Скачал. Запустил.
Результаты не понятные.
При включении "Profiling mode" все начинает тупить в не зависимости от CUDA, OpenCL
Есть подозрение, что приложение написано криво.
Мне ковыряться в коде в лом.

PS. Есть подозрения, что OpenCL работает медленее CUDA на Nvidia. OpenCL выступает в качестве прослойки между CUDA Driver API. Но информация не точная и не проверена.

asvp
> PS. Есть подозрения, что OpenCL работает медленее CUDA на Nvidia. OpenCL
> выступает в качестве прослойки между CUDA Driver API. Но информация не точная и
> не проверена.
Я читал, что OpenCL на NVIDIA использует CUDA, т.е. OpenCL как обертка над CUDA

ialexbr
> Я читал, что OpenCL на NVIDIA использует CUDA, т.е. OpenCL как обертка над CUDA
Ну а я о чем.
"выступает в качестве прослойки между CUDA Driver API" и вышим приложением.
CUDA имеет две API.
Высокоуровневое и низкоуровневое.

Высокоуровневое лежат в спец. DLL. (cublas32_xx.dll, cudart32_xx.dll, cufft32_xx.dll).
Т.е. с вашим приложением нужно будет носить используемые DLL.
Распространяются только с CUDA Toolkit.
При обновлении дров не обновляются.

низкоуровневое лежит в nvcuda.dll для Nvidia (для OpenCL nvopencl.dll)
Распространяются и обновляются с дровами.
"CUDA Driver API" это именно nvcuda.dll.
С вашим приложением ничего дополнительного носить не нужно.
Минусы: Многое нужно писать самому.
Плюсы: Ниже только ядро оси и GPU.

Одним словом. Юзайте OpenCL.
1. Кроссово (NVidia, Intel, AMD, Android, Linux)
2. OpenCL имеет ряд преимуществ по сравнению с GLSL.
Для примера:
GLSL для просчета 1 пикселя запускается 1 шейдер и обратится к соседнему пикселю, которые должен быть просчитан в другом шейдере не возможно. Необходимо запускать второй проход.
В OpenCL (да и в CUDA) такое можно реализовать. Т.е. взять результат просчитанные в другом треде без повторного запуска всего ядра.

3. GLSL имеют ограничения по размерам текстур. У OpenCL размеры текстур могут быть гораздо больше. По сути OpenCL работает с 1D, 2D, 3D массивами данных. И чем больше размерность этих массивов, тем OpenCL эффективнее.
Поэтому при работе с OpenCL выгодно отправлять сразу несколько массивов с разными ядрами обработки, а потом получать весь результат. OpenCL очень хорошо сосчитается с многопоточностью.
Чтобы нагрузить OpenCL по-настоящему нужно еще постараться.
4. Получите большой опыт в написании программ для обработки больших огромнных ах...нных массивов данных.

Посмотрите примеры из CUDA Toolkit
nbody.exe - для каждой точки просчитывается взаимодействие с другим 16К - 1 точек. Задача N-тел. Название доки "Fast N-Body Simulation with CUDA. GPU Gems 3. Chapter 31"
При 16К 60 fps стабильно.

ialexbr
> Опять же привожу в пример видео сравнение:
> https://www.youtube.com/embed/aJCcqa87ZsQ. Если у Вас есть друге сравнения,
> буду рад их увидеть.
Чем такие сравнения смотреть - лучше вообще никаких не смотреть. Последнее сравнение, 0xFFFF частиц. У OpenCL время около 50мс на фрейм, у CUDA 25мс. При этом за одно и то же время на OpenCL орендерилось 35 фреймов, на CUDA - 280. В 8 раз разница по фреймам, да?
Без исходного кода смотреть, что именно автор там намерил нет смысла.

ialexbr
> Если у Вас есть друге сравнения, буду рад их увидеть.
https://www.youtube.com/watch?v=OoCdycNp0pY&feature=youtu.be&… ion_994386255
http://www.efxi.ru/more/premiere_pro_cs65_amd.html

MrShoor
Ну это измерения в стиле "так приложить линейку, чтобы у автора намерилось 30 см".

А как дела обстоят с распараллеливанием на OpenMP - по идее он для ручного управления потоками видеокарт изначально создавался?

Odin P. Morgan
> OpenMP - по идее он для ручного управления потоками видеокарт изначально создавался
Кто вам сказал, что он создавался для видеокарт?

asvp
> Одним словом. Юзайте OpenCL.
> 1. Кроссово (NVidia, Intel, AMD, Android, Linux)
OpenCL под Android на чем выполняется, на GPU тоже может? Или только на CPU?

А вообще вы все меня убедили, что стоит использовать OpenCL.

ialexbr
> OpenCL под Android на чем выполняется, на GPU тоже может? Или только на CPU?
Под GPU.
Может и на CPU. Это основное отличие от CUDA. OpenCL может работать на CPU в отличие от CUDA. CUDA только на GPU.

> А вообще вы все меня убедили, что стоит использовать OpenCL.
И... Это правильное решение. Вы получили +1 опыта.

>А как дела обстоят с распараллеливанием на OpenMP
Если вам нужно распараллелить вычисления, которые длятся порядка секунд и дальше, то OpenMP годится. Если цикл, который требуется параллелить, работает меньше 100мс, то рискуете всё только замедлить. А в профайлере вы случайно заметите что с OpenMP 80% времени будет пропадать в _beginthreadex.

Вообщем последний раз там была хреновая реализация, в которой потоки стартуют по месту. К применению не рекомендуется. Если кто расскажет, как на практике заставили OpenMP работать с пулом потоков, созданым зараннее, возьму слова обратно.

Сейчас всякие крутые дядьки (OpenCV) используют Intel TBB чтобы сишный код параллелить.

frost
> крутые дядьки (OpenCV) используют Intel TBB
Крутые дядьки могут позволит 700 американских рублей выложить.

> Если вам нужно распараллелить вычисления, которые длятся порядка секунд и дальше, то OpenMP годится.
На 100% согласен.

> Вообщем последний раз там была хреновая реализация, в которой потоки стартуют по месту.
Это не плохая реализация, это сама сущность OpenMP. Он тем и плох, что обработка данных выполняется в определенном месте (в теле функции н-р). За пределам он уже не живет.
А при каждом начале параллельного блока OpenMP пул потоков создается заново (если что-то не поменяли). После завершения параллельного блока потоки закрываются.

> Если кто расскажет, как на практике заставили OpenMP работать с пулом потоков, созданным заранее, возьму слова обратно.
На практике пришлось писать свой велик, т.к. у OpenMP небыло такого функционала.

>Это не плохая реализация, это сама сущность OpenMP
Мы в своё время всерьёз подумывали поправить реализацию OpenMP к GCC, дабы была возможность работать с ручным пулом потоков, например через какой-нибудь сишный API. (На деле вызовы openmp маппятся компилятором в конкретный API, который можно реализовать (или поправить) самому, благо исходники под рукой) Но в итоге свой велосипед оказался куда быстрее в реализации, а на опенсорс благотворительность мы как-то позабили )