Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Тяжелые SIMD вычисления и OpenCL

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Какую универсальную технологию посоветуете для тяжелых векторно-матричных вычислений (kernel-calculations), чтобы задействовать для этого тот же GPU. Пока в рейтинге по универсальности побеждает OpenCL.

Хотелось бы спросить, насколько хорошо он работает на смартфонах и есть ли технология более универсальные.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хмм... Вычисления на мобилках? Тебе только вывести на экран? Тогда тебе в GLSL. Если тебе еще и вытащить надо результат дял последующей работы, то я бы использовал расширения OpenGL ES для чтения FBO. Есил поставить высокую точность флоата, то неплохо проканает. Хотя, опять же, зависит. Ну и будут проблемы с самой текстурой (есил у тебя флоаты), но не смертельные на данном этапе развития ES ( www.khronos.org/...xture_float.txt или запаковка флоата в лоб в vec4 с последующей распаковкой на стороне проца). Если считаешь термодинамику, где и дабла зачатую не хватает, то я бы на твоем месте вообще забыл о чем-то симдоподобном на мбоилках и писал бы в лоб на С с оптимизацией под каждую конкретную платформу по реквесту клиента.

Как вариант, не искал обход решения не в лоб? Например, при фильтровании перейти в тот же домен фурье и прозивести свертку (если твоя задача позволяет, конечно)?

А об OpenCL я бы на твоем месте на мобилках пока забыл, не пришло еще его время.

Ну мобилки это больше как опция. Скорее всего будет или для PC или для встроенных устройств, где может быть ARM или другой не интеловский процессор.

Мне можно сказать для этого класса алгоритмов.
en.wikipedia.org/...region_detector

Ну мобилки это больше как опция. Скорее всего будет или для PC или для встроенных устройств, где может быть ARM или другой не интеловский процессор.

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

Ну у заказчика стоят в заказе, как можно больше числовіх платформ, причем код будет потом еще портирован на Java и ObjectC. Так что платформа — все в чем есть камера и процессор. Собственно в этом и фишка продуктов в Aspose, от мощных серверов, до дешевых смартфонов. Они реально абсолютно универсальны.
www.aspose.com

Как вариант, не искал обход решения не в лоб? Например, при фильтровании перейти в тот же домен фурье и прозивести свертку (если твоя задача позволяет, конечно)?

Совершенно не представляю как с помощью фурье вычислить соответствие двух изображений и параметры их афинного преобразования для наложения. По сути фурье в обработке изображение редко используется, слишком уж это иной класс алгоритмов.

Совершенно не представляю как с помощью фурье вычислить соответствие двух изображений и параметры их афинного преобразования для наложения.

Откеда я знал, что ты соответствие ищешь? В начале темы не сказано ни слова. Хотя, более чем уверен, дял него тоже есть более оптимальные пространства, но делать за тебя твою работу я не буду ,извини.

По сути фурье в обработке изображение редко используется, слишком уж это иной класс алгоритмов.

О как? В гробу вертицца все дсп сообщество, т.к. сдохло от смеху после твоего авторитетного заявления (претенциозного и, как обычно, не имеющего ничего общего с действительностью). Я так понимаю, свертка, слепая развертка, слепое разделение источников, фингерпринтинг, компрессия и т.п. — это мелочи, которые в обработке изображений с твоей точки зрения не используюцца? Расскажи еще какую-нить чушь, а то еще не все дспшники на планете вымерли от смеху над тобой.

Для 2D-вертки используются вейвлеты, а совсем не фурье.
ru.wikipedia.org/wiki/Вейвлет

trimm — советую вылезти с шахты и пройти хоть самостоятельно самому курс, который проходили все с дипломом по IT-специальности. А то твоя глупость действительно эйнштейновска.
Эйнштейн: «Две вещи действительно бесконечны: Вселенная и человеческая глупость. Впрочем, насчет Вселенной я не уверен».

Если надо чтобы реально работало — то CUDA. OpenCL за все эти годы так и остался игрушкой — ни библиотек, ни инструментов.

Да, да, особенно CUDA чудо как хороша в качестве _кросплатформенного_ и _мобильного_ продукта, ни тебе поддержки процессоров, ни кастомных DSP.

Если надо чтобы работало — CUDA. Мультиплатформенность на месте. Если надо обещания — OpenCL. Кто сказал что автору топика нужны кастомные DSP? И что толку от дохлых мобильных GPU в OpenCL? Использовать основной процессор более эфективно — по батарейке и по производительности.

CUDA реально используется в суперкомпьютерах, медицинском оборудовании, обработке видео.

Если надо чтобы работало — CUDA. Мультиплатформенность на месте. Если надо обещания — OpenCL.
Как-то сильно голословно.
Кто сказал что автору топика нужны кастомные DSP?
Почему кастомные? При использовании OpenCL к ним можно получить доступ.
И что толку от дохлых мобильных GPU в OpenCL?
Вопрос изначально звучал про мобильные платформы, этот вопрос — совершенно другая тема.
Использовать основной процессор более эфективно — по батарейке и по производительности.
Бабушка надвое сказала. Всё очень зависит от конкретного устройства.
CUDA реально используется в суперкомпьютерах, медицинском оборудовании, обработке видео.
CUDA — это вчерашний день, завязываться на одного производителя небезопасно.

CUDA сейчас как раз наиболее активно используется для GPGPU. OpenCL, к сожалению, не может предоставить такую же производительность как CUDA (хороший пример — рейтрейсинг, CUDA легко генерит большее количество fps, чем OpenCL). Проблема CUDA — мобильные платформы не очень ее поддерживают (точнее очень ее не поддерживают).
Кроме OpenGL ES есть еще вариант использовать Cg, но я не уверен насколько он поддерживается на смартфонах.
Другой момент, который надо учитывать — это то, что если есть возможность минимизировать считывания из памяти и использовать значения «соседних» кернелов, то можно будет снизить количество вычислений. Тогда может быть не понадобится уж сильно высокая производительность.

CUDA не поддерживает ни Интел ни AMD. А вот OpenCL довольно неплохо ляжет на ихню HD.

Опять же, проект который стартует это не программно-аппаратный комплекс, а программный, так что универсальность даже важнее производительности. Оборудование будет покупать покупатель библиотеки, и ему может очень не понравится hardware lock.

CUDA сейчас как раз наиболее активно используется для GPGPU. OpenCL, к сожалению, не может предоставить такую же производительность как CUDA
К сожалению, вина за текущее положение дел лежит 100% только на nVidia. Не знаю, маркетинг это или нет толковых программеров, но это их и только их проблема.
(хороший пример — рейтрейсинг, CUDA легко генерит большее количество fps, чем OpenCL)
Переведите все расчёты на double, и посмотрите результат. Когда я последний раз делал сравнение на GTX480 разница была призрачная в районе нескольких процентов, причём не всегда побеждала CUDA.
Проблема CUDA — мобильные платформы не очень ее поддерживают (точнее очень ее не поддерживают).
У CUDA куда больше проблем.
Кроме OpenGL ES есть еще вариант использовать Cg, но я не уверен насколько он поддерживается на смартфонах.
OMFG, сейчас Cg — это недо HLSL/GLSL от nVidia, т.к. он появился раньше их и сейчас не особо то и нужен.

У CUDA меньше проблем чему OpenCL. Но вы уже продемонстрировали полное незнание предметной области.

Я так понимаю, что вы имеете полное знание предметной области, поэтому продемонстрируйте все pros и cons. А я с удовольствием посмотрю на глубину знаний и непредвзятость. Here you go.

Могу сказать только pros и cons для CUDA (по крайней мере те, которые заметил).
Pros:
1) DMA access over the network между видео картами (без использования CPU)
2) При грамотном написании алгоритма вычисления выполняются действительно очень быстро (пример из жизни — Монте Карло для симуляции фотонов позволяет использовать одну Tesla M2050 вместо кластера из 200 нод)
3) Interop с DirectX и OpenGL (если не ошибаюсь у OpenCL были некоторые проблемы с DirectX11)
4) Наличие GPU, которые специально созданы для GPGPU от NVIDIA
5) Возможность рекурсивного вызова кернелов
6) Наличие асинхронных потоков
Cons:
1) Предназначена для работы на GPU only. Причем только NVIDIA. Но я в этом не вижу ничего страшного, т.к. прогресс NVIDIA в этой области делает семимильными шагами.
2) При наличии нескольких GPU надо писать код, который будет управлять разделением задач между ними.

1) DMA access over the network между видео картами (без использования CPU)
Эээ, какой network? DMA доступ для PCI/PCI-E устройств — одно из фундаментальных свойств шины, его используют все. По большому счёту всё-равно какой участок памяти брать и куда ложить.
2) При грамотном написании алгоритма вычисления выполняются действительно очень быстро (пример из жизни — Монте Карло для симуляции фотонов позволяет использовать одну Tesla M2050 вместо кластера из 200 нод)
Или взять одну Radeon HD 4870 X2 и OpenCL и получить в два раза больше терафлопсов. О цене решения я просто тактично умолчу.
3) Interop с DirectX и OpenGL (если не ошибаюсь у OpenCL были некоторые проблемы с DirectX11)
??? Я такого не слышал, может у какого-то производителя были временные проблемы с драйверами?
4) Наличие GPU, которые специально созданы для GPGPU от NVIDIA
Сомнительный pros, а восьмиядерный Xeon делает терафлопс, вот только CUDA его не будет использовать.
5) Возможность рекурсивного вызова кернелов
Существует ряд способов обойти это ограничение на OpenCL, да и сама рекурсия — не средство первой необходимости. В общем этот pros принимается.
6) Наличие асинхронных потоков
Поддерживается в OpenCL немного в другом виде.
1) Предназначена для работы на GPU only. Причем только NVIDIA. Но я в этом не вижу ничего страшного, т.к. прогресс NVIDIA в этой области делает семимильными шагами.
Остальные тоже далеко не аутсайдеры :)
2) При наличии нескольких GPU надо писать код, который будет управлять разделением задач между ними.
Ну в OpenCL тоже необходимо задавать out-of-order execution если код будет выполнятся в разных средах и на разных средствах и ручками менеджить его . Это нормально.

RDMA — можно через сеть иметь доступ между двумя видео картами, не прибегая к помощи RAM. Radeon HD 4870×2, во-первых, имеет 2 GB памяти (против 6), во-вторых, пропускная способность его ниже, в-третьих, взгляните на Kepler и вы поймете, что один ГПУ от NVIDIA обходит Radeon. Рекурсия очень сильно нужна при рендеринге и симуляции Fluid Dynamics. Но основное это конечно же надо уметь правильно писать код и алгоритмы, хотя это для всего надо. На самом деле я считаю OpenCL тоже отличным языком, но как говорится надо писать на том языке, который делает тебя счастливым. Для GPGPU у меня это CUDA. Как только будет время, разберусь более подробно с OpenCL и мое мнение может быть поменяется. Я больше ничего не буду писать сюда, а то это уже начинает переходить в холивар по типу Java vs C#, да и автору топика это никак не помогает для решения изначальной проблемы((

во-первых, имеет 2 GB памяти (против 6),

Это не особо и важно, осбенно если взять более дешевую карту от нвидии.
fotos.ua/...0-dc2-4gd5.html

4Гб На борту и 1536 ядра за 630$ это намного лучше 6Гб На борту и 448 ядер за 2100$.

RDMA — можно через сеть иметь доступ между двумя видео картами, не прибегая к помощи RAM.
Вы не совсем понимаете суть RDMA. Сетевая железка обычно тупо работает с памятью как scatter-gather DMA и ей по большому счёту всё равно откуда забирать данные — из системной памяти или видеопамяти. RDMA по сути это программная надстройка над сетевым драйвером — не более того.
Radeon HD 4870×2, во-первых, имеет 2 GB памяти (против 6), во-вторых, пропускная способность его ниже, в-третьих, взгляните на Kepler и вы поймете, что один ГПУ от NVIDIA обходит Radeon.
Задачи разные бывают, или я делаю атаку на хэш-функцию, брутфорсю сайфер, сжимаю видео — мне не нужна сумасшедшая пропускная способность и много памяти, мне нужны только терафлопсы. В этих задачах GPU от nVidia проиграет в разы, но которые стоят неадекватно поставленным задачам.
Рекурсия очень сильно нужна при рендеринге и симуляции Fluid Dynamics.
Рекурсии всегда можно избежать, храните данные не в стеке, а в массиве, какая по сути разница? Тут отдана дань универсальности OpenCL, есть устройства, взять тот же IntelHD SandyBridge, у которого 256 GP регистров по 1024 бит на kernel, сохранять все регистры в стеке (32Kb данных) ради рекурсии — пустая трата производительности, проще значения пары десятков регистров, которые описывают внутреннее состояние функции сбросить в scratch память.
Или взять одну Radeon HD 4870 X2 и OpenCL и получить в два раза больше терафлопсов. О цене решения я просто тактично умолчу.

Бенчмарк в монтекарло предоставите — или оперируете маркетинговыми цифрами? Особенно с генератором случайных чисел (на CUDA есть curand).

Остальные тоже далеко не аутсайдеры :)

Да неужели. И сколько в top500 NVIDIA — и сколько PowerVR? Ну или ATI?

Бенчмарк в монтекарло предоставите — или оперируете маркетинговыми цифрами? Особенно с генератором случайных чисел (на CUDA есть curand).
Без проблем, давайте код для OpenCL, потестим.
Да неужели. И сколько в top500 NVIDIA — и сколько PowerVR? Ну или ATI?
Причём тут PowerVR? Это не та ниша. В top500 есть приличное количество и кастомных DSP и FirePro S10000, которые уделывают Tesla K10, причём не по маркетинговым данным, а по реальным бенчмаркам.
Без проблем, давайте код для OpenCL, потестим.

Это вы утверждаете что ATI быстрее.

В top500 есть приличное количество и кастомных DSP и FirePro S10000, которые уделывают Tesla K10, причём не по маркетинговым данным, а по реальным бенчмаркам.

Только вот Tesla там больше. K10 сильно специфичный акселератор — и в работе с целыми числами он очень эффективен.
Как вы думаете, перед тем как Cray новый кластер собирает — они сравнивают акселераторы? Почему же тогда Tesla более популярны? Потому что вас не спросили?

Это вы утверждаете что ATI быстрее.
Мое утверждение базируется на реальных бенчмарках, если вы не верите — ваше право, давайте код, будем смотреть.
Как вы думаете, перед тем как Cray новый кластер собирает — они сравнивают акселераторы?
А Cray такие профаны, что используют в top n1 и CUDA и OpenCL, ибо понимают, что 299008 opteron’ов не могут просто так простаивать. Я правильно понимаю, что они профаны исходя из ваших утверждений, они не читали ваших ответов на stackoverflow?

А перед тем как сделать top n2 суперкомпьютер IBM сравнивает акселераторы и предпочитают кастомные DSP.

Почему же тогда Tesla более популярны?
Никто не отрицает, что они популярнее остальных, но это не даёт право называть других аутсайдерами. Это попахивает каким-то детским снобизмом...
Мое утверждение базируется на реальных бенчмарках, если вы не верите — ваше право, давайте код, будем смотреть.

Я не верю что вы видели реальные бенчмарки в Monte-carlo.

Никто не отрицает, что они популярнее остальных, но это не даёт право называть других аутсайдерами.

Скачиваем top500 (есть Excel).

49 Тесл, 3 — ATI. ATI таки аутсайдеры. Хваленых IBM — 2. Только Intel на что-то похож (7 штук)

Я не верю что вы видели реальные бенчмарки в Monte-carlo.
А я нигде и не говорил, что я видел бенчмарки Monte-carlo, мне других floating point бенчмарков хватило за глаза.
49 Тесл, 3 — ATI. ATI таки аутсайдеры. Хваленых IBM — 2. Только Intel на что-то похож (7 штук)
49 тесл из 500 — nVidia аутсайдер в таком случае.
А я нигде и не говорил, что я видел бенчмарки Monte-carlo, мне других floating point бенчмарков хватило за глаза.

Ну да-ну да. Не читал но осуждаю.

49 тесл из 500 — nVidia аутсайдер в таком случае.

9.8% — уже не аутсайдер. Вот 0.4% — это да.

Ну да-ну да. Не читал но осуждаю.
До тех пор пока тут nVidia пасёт задних, мне искренне всё равно, что в каком-то специально-написанном тесте она показывает лучшие результаты.
clbenchmark.com/result.jsp
9.8% — уже не аутсайдер. Вот 0.4% — это да.
А я считаю, что и 10% — это таки аутсайдер.
А я считаю, что и 10% — это таки аутсайдер.

Если учесть что эти 10% и есть весь рынок — то ваша глупость проявляется особо ярко.

Если учесть что эти 10% и есть весь рынок — то ваша глупость проявляется особо ярко.
Я правильно понимаю вашу глупость, что 90% рынка суперкомпьютенга жалкие аутсайдеры и только 10% явные лидеры?

Берем первую десятку — 2 из 10 с теслами, 1 — Фи. В двадцатке — 4 Тесл. Очевидно что более современные системы находятся ближе к вершине списка.

Если бы вы хотели вести аргументированную дискуссию (вы не сослались ни на один источник), то вы бы уже признали очевидное — рынок молодой, тенденция очевидна. Со временем остальные тоже прийдут к гетерогенным архитектурам. IBM и ATI в топовые системы не ставят.

Если бы вы хотели вести аргументированную дискуссию (вы не сослались ни на один источник)
Женя, с Вами вообще неприятно вести дискуссию в любом виде, вместо конструктивного разговора идёт переключение на личности и озвучивание своего IMHO.
то вы бы уже признали очевидное — рынок молодой,
Мда, рынок суперкомпьютинга активно развивается с 80х годов, о какой молодости можно говорить? Или речь о GPGPU? Сейчас отходят от GPGPU в пользу кастомных решений, какое-то время текущая концепция GPGPU ещё будет держаться в текущем виде, но она тоже трансформируется, GPU в текущем виде там делать нечего.
Со временем остальные тоже прийдут к гетерогенным архитектурам.
Правильно, все идут к гетерогенным архитектурами, гомогенные GPGPU отживают свой срок.
Или речь о GPGPU? Сейчас отходят от GPGPU в пользу кастомных решений, какое-то время текущая концепция GPGPU ещё будет держаться в текущем виде, но она тоже трансформируется, GPU в текущем виде там делать нечего.

Почему Intel с вами не консультируется? Xeon Phi всякие выпускает.

Так понимаю, вам такое в руки ещё лет 30 не дадут — «OpenCL реализовывать»?

Почему Intel с вами не консультируется? Xeon Phi всякие выпускает.
Ссылку, плиз, на то, что Xeon Phi — это GPGPU. Xeon Phi — это как раз продукт отхода от концепци GPGPU.
Так понимаю, вам такое в руки ещё лет 30 не дадут — «OpenCL реализовывать»?
Женя, я проходил собеседование в nVidia, и прошёл на позицию далеко не tools developer’а, поэтому попытки меня ущемить выглядят очень жалкими.
Ссылку, плиз, на то, что Xeon Phi — это GPGPU. Xeon Phi — это как раз продукт отхода от концепци GPGPU.

Термин есть — «акселератор». Так столбец в top500 называется. Tesla — в том же столбце. Tesla тоже без видеовыхода, странно его GPU называть.
GPGPU — это исторический термин, не совсем действительности соответствует.

Женя, я проходил собеседование в nVidia, и прошёл на позицию далеко не tools developer’а

...но предпочли работать с устаревшим железом под более примитивными ОС.

Термин есть — «акселератор». Так столбец в top500 называется. Tesla — в том же столбце.
Вы же вроде взрослый человек, какая разница где находится «акселератор», на одной подложке с процессором или вынесен в другой чип?
А теперь посмотрим на цифры,
560640 ядер — 17590.0 Tflops
1572864 ядер на частоте 1.6Ghz — 16324.8 Tflops, и посчитайте кто работает быстрее на 1MHz или 1 Wt затраченной работы. И кого можно назвать «акселератором»?
Tesla тоже без видеовыхода, странно его GPU называть. GPGPU — это исторический термин, не совсем действительности соответствует.
Дело не в видеовыходе, Tesla до сих пор считает floating point по альтернативным правилам или уже перешли на IEEE 754 как все остальные? Вот когда скорость не будет приоритетом по сравнению с точностью, вот тогда это уже не будет GPGPU.
...но предпочли работать с устаревшим железом под более примитивными ОС.
Я ещё также прошёл в ATI/AMD, но предпочёл развиваться, работая с разными архитектурами, чем с одной у одного вендора. Устаревшее железо с которым я работаю часто появится на рынке только через пол года — год. Я не могу в линкедине писать о них и о других подобных продуктах :) Если это камень в огород Matrox P-series, то их современная архитектура уделывает nVidia по организации и по скорости 2D операций, а главное качеству картинки, а многим заказчикам другого и не надо. А покупают именно их по цене топовых nVidia акселераторов, а не nVidia. Почему? Тоже самое на embedded рынке, туда nVidia не пускают, а их попытки зайти на второй тегре провалились. По поводу примитивности ОС, о чём можно говорить с человеком, который не разбирается в предметной области (RTOS) и какой смысл спорить с его профанскими суждениями?
Берем первую десятку — 2 из 10 с теслами, 1 — Фи. В двадцатке — 4 Тесл. Очевидно что более современные системы находятся ближе к вершине списка.
Вот решил проверить ваши слова и как всегда нашёл кучу нестыковок и подтасовок, последний список Ноября 2012:

www.top500.org/lists/2012/11

1. nVidia
2. IBM
3. Fujitsu
4. IBM
5. IBM
6. IBM
7. Dell/Phi
8. nVIdia.
9. IBM
10. IBM

2 — nVidia, 6 — IBM, 1 — Fujitsu, 1- Dell/Phi.

Кто аутсайдер?

11. Bull/Xeon
12. nVidia
13. IBM
14. SGI/Xeon
15. Bull/Xeon
16. IBM
17. nVidia
18. Cray/custom
19. Cray/custom
20. Bull/custom.

8 — IBM, 4 — nVidia, кто аутсайдер?

нашёл кучу нестыковок и подтасовок

Да неужели. Недодрайверописатели не умеют с данными работать?

2 — nVidia, 6 — IBM, 1 — Fujitsu, 1- Dell/Phi.
Кто аутсайдер?
8 — IBM, 4 — nVidia, кто аутсайдер?

Вы же били себя пяткой в грудь что IBMовские акселераторы а не PPC системы всех заруливают. Я же сказал — смотреть надо Excel, там есть колонка Accelerator. в ней и видно что самый верхний IBMовский акселератор — на 23-м месте, система RoadRunner. Все системы IBM что выше — без акселераторов, просто PowerPC.

Теперь жду врак, которые начнут векторные сопроцессоры (и всякие наборы SIMD инструкций) приравнивать к специализированному железу.

Да неужели. Недодрайверописатели не умеют с данными работать?
Это то, о чём я говорил, аргументы закончились?
Вы же били себя пяткой в грудь что IBMовские акселераторы а не PPC системы всех заруливают.
Ссылку пожалуйста на то, где я это говорил.
Теперь жду врак, которые начнут векторные сопроцессоры (и всякие наборы SIMD инструкций) приравнивать к специализированному железу.
И в чём разница для достижения результата и для конечного потребителя? От того, что оно выполняется в «акселераторе», не делает его самым быстрым. Или заказчик должен оргазмировать просто от того факта, что в его суперкомпьютере работает «акселератор» от nVidia? Я думал, что взрослым дядям нужен результат.
Ссылку пожалуйста на то, где я это говорил.

Вот:

IBM сравнивает акселераторы и предпочитают кастомные DSP.

Все top-20 IBM системы — чистый CPU.

И в чём разница для достижения результата и для конечного потребителя?

Юлите, сер.

Все top-20 IBM системы — чистый CPU.
Сам процессор идёт без floating point юнита вообще, всю работу выполняет AXU, зашитый на подложке впесте с процессором. Такие же AXU есть и не на подложке. Цитата: “Such facilities are handled by the AXU, which has support for any number of standardized or customized macros, such as floating point units, vector units, DSPs, media accelerators and other units with instruction sets and registers not part of the Power ISA. The core has a system interface unit used to connect to other on die cores, with a 256-bit interface for data writes and a 128-bit interface for instruction and data reads at full core speed.”
Юлите, сер.
Ещё раз, потребителю положить на то как внутри это сделано, ему важен результат. Ему всё-равно стоит там Tesla в виде коробочки или AXU, спрятанный в процессоре.
Я так понимаю, что вы имеете полное знание предметной области

Я даже на StackOverflow в top-20 отвечающих на вопросы по CUDA. А у вас — только мания величия.

А я с удовольствием посмотрю на глубину знаний и непредвзятость.

А с чего это вам можно говорить полную неграмотную чушь а я должен быть непредвзятый.

Простые факты:
1. Все современные мобильные акселераторы, которые заявляют OpenCL — не создавались для GPGPU. Т.е. они не умеют управлять питанием при GPGPU нагрузках, у них нет оптимизаций под всякие атомики/барьеры, т.д. Поэтому я и говорю что лучше уж CPU использовать.
2. Open CL не позволяет использовать все особенности железа — например, на CUDA можно порождать задачи без участия CPU.

Я даже на StackOverflow в top-20 отвечающих на вопросы по CUDA. А у вас — только мания величия.
Я за вас искренне рад, а вот с манией величия мимо тазика ... ну это же не я в top20 и трезвоню об этом на каждом углу ? :)
А с чего это вам можно говорить полную неграмотную чушь а я должен быть непредвзятый.
Или вы отвечаете конструктивно на то, что считаете «чушью», или просто не повышаете энтропию пустыми выкидами. Я деньги получаю не за ответы на stackoverflow, а за различные имплементации и OpenGL и OpenCL.
1. Все современные мобильные акселераторы, которые заявляют OpenCL — не создавались для GPGPU. Т.е. они не умеют управлять питанием при GPGPU нагрузках, у них нет оптимизаций под всякие атомики/барьеры, т.д. Поэтому я и говорю что лучше уж CPU использовать.
Тоже факт: у nVidia нет публичной мобильной CUDA и она обещается только для Tegra4, с чем сравниваем? К чему этот выпад? OpenCL разрабатывался для гетерогенных вычислений, в том числе и для GPGPU, это накладывает некоторые ограничения, но в этом же и его преимущество. По поводу оптимизации — звучит как-то непрофессионально, всё зависит от конкретной имплементации и если у nVidia с этим всё плохо, то это не вина OpenCL.
2. Open CL не позволяет использовать все особенности железа — например, на CUDA можно порождать задачи без участия CPU.
Я не вижу причин, по которым конкретная имплементация OpenCL не может реализовать запуск kernel’ов без CPU, если вендор считает это принесет эффективность для работы его железки, то всё в его руках.
Я не вижу причин, по которым конкретная имплементация

Пропустил основную часть дискуссии. Но от того что что-то там потенциально может быть программа на напишется. Надо чтобы было, сейчас и с документацией

Правильно, и в этом вина nVidia.

Хм, так они же вроде не хотят чтобы OpenCL был. Можно написать им гневное письмо

От их хотят или не хотят мало что зависит. Для крупных корпоративных клиентов они делают всё, что они просят :)

Я деньги получаю не за ответы на stackoverflow, а за различные имплементации и OpenGL и OpenCL.

Именно поэтому CUDA и лидирует.

По поводу оптимизации — звучит как-то непрофессионально, всё зависит от конкретной имплементации и если у nVidia с этим всё плохо, то это не вина OpenCL.

У нас акселераторы отлично заточены под GPGPU. Лучше всех на рынке.

Я не вижу причин, по которым конкретная имплементация OpenCL не может реализовать запуск kernel’ов без CPU, если вендор считает это принесет эффективность для работы его железки, то всё в его руках.

Как я и сказал — если надо чтобы работало — то CUDA. OpenCL — пустые обещания и теория.

Если числодробилки на своем железе, то естественно. Но если надо делать софт для домашних пользователей, то CUDA когда я последний раз проверял на ATI не работала.

Как там дела у OpenCL на встроеных картах Intel? Насколько помню, там сильно всё глючило.

Очень даже не плохи дела.

У нас акселераторы отлично заточены под GPGPU. Лучше всех на рынке.
И тем не менее ATI/AMD довольно-таки успешно конкурируют.
Как я и сказал — если надо чтобы работало — то CUDA. OpenCL — пустые обещания и теория.
Так как раз эти обещания «самая лучшая в мире компания» и не выполняет перед пользователями. Ото Cray дурачки юзают OpenCL, забыли у Жени спросить его мнение?
Ото Cray дурачки юзают OpenCL, забыли у Жени спросить его мнение?

А они бы могли использовать CUDA?

Там в основном CUDA Fortran, OpenACC, CUDA C — OpenCL используют только те, кому важен не результат а слово «open» в названии технологии.

.

Они используют и то и другое и третье. Всё зависит от клиента, который арендует мощностя. Если клиент придёт с готовой задачей на OpenCL (а таких реально много), то будет глупо им отказывать только потому что кто-то в nVIdia не любит OpenCL.

И тем не менее ATI/AMD довольно-таки успешно конкурируют.

Сеперкомпьютеры (я выше привел статистику) — ATI в рамках стат. погрешности. Проф рынок — тоже. Мобильных ATI нет и в планах. Они только в PC и представлены, довольно слабо (там Intel)

Пошел на хотлайн. Статистика количества ноутбуков по видеокартам

Intel (867)
NVIDIA (674)
AMD (580)

И что количество _моделей_ ноутбуков говорит? Вот у Apple — пара моделей. А в Штатах, например, они состовляют 14% продаж ноутов.

Но это количество моделей десятков производителей, которые продаются (а следовательно востребованы) на рынке. В любом магазине продаются компьютеры с Intel, Nvidia, ATI. ATI на несколько процентов меньше, что и подтверждается этой статистикой. Не верить ей — одеть калоши на глаза и верить внутренней корпоративной политике и статистике от самой Nvidia ;)

Посмотришь на квартальные отчеты — не шибко эти сотни моделей и продаются. Надо смотреть статистику Стима (сейчакс лежит) — насколько я помню, там Intel всех задавил.

Проф рынок — тоже.
ATI дохрена на проф рынках, особено в медицине.
Ото Cray дурачки юзают OpenCL

Cray давно уже разочаровался в OpenCL (если когда-либо вообще интересовались) — вы с Open ACC случаем не путаете?

Жени

Фамильяроность как на базаре.

Cray давно уже разочаровался в OpenCL (если когда-либо вообще интересовались) — вы с Open ACC случаем не путаете?
Можно proof?
Фамильяроность как на базаре.
Не надо было первым переходить на личности.
Можно proof?

Cray не участвует в OpenCL стандарте — они занимаются OpenACC.

Не надо было первым переходить на личности.

ORLY!

Cray не участвует в OpenCL стандарте — они занимаются OpenACC.
И всё-таки можно proof на то, что «Cray давно уже разочаровался в OpenCL», то что он не учавствует в обсуждениях стандарта — ни о чём не говорит, за них это делают вендоры железа.
за них это делают вендоры железа

Вы совсем не понимаете как этот рынок устроен.

Вы совсем не понимаете как этот рынок устроен.
Как всегда голословно, я уже другого не ожидаю, о конструктиве и говорить не приходится.

Универсальный вариант (особенно с бизнес-точки зрения) — это свой RPC сервер с FPGA ускорителями. Но тут конечно все от приложения зависит.

Особенно если это библиотека, используемая, сторонними разработчиками.

А что есть трудности вынести RPC функционал в библиотеку и добавить customer ID к параметрам ?

Да и запихивать в сматфоны :)

Коментар порушує правила спільноти і видалений модераторами.

Какую универсальную технологию посоветуете для тяжелых векторно-матричных вычислений (kernel-calculations), чтобы задействовать для этого тот же GPU. Пока в рейтинге по универсальности побеждает OpenCL.
Универсальное только одно — OpenCL.
Хотелось бы спросить, насколько хорошо он работает на смартфонах и есть ли технология более универсальные.
У PowerVR есть OpenCL для SGX мобильной серии графических акселераторов. Вот только её включили в поставку единицы из производителей смартфонов, т.е. её практически нигде нет.

Работает настолько хорошо, что при хорошем загрузе SGX554 сожрёт батарею за час-полтора, SGX545 за полтора-два часа с охренительным тепловыделением. Вот и спрашивается, зачем оно надо на мобильных платформах?

nVidia обещала поддержку OpenCL в Tegra 4, но это будет совсем не бюджетная сфера, да и по потреблению врядли далеко уйдёт от PowerVR.

Работает настолько хорошо, что при хорошем загрузе SGX554 сожрёт батарею за час-полтора

Ну час загруза не нужен, нужно где-то 200-500 мсек в минуту. Так что нагрузка будет пиковая и неравномерная. Ну или при полном загрузе, будет 2-3 сек на обработку документа, что реально для батареи не проблема, так как девайс будет для этого встроенный с кормлением от розетки.

Вот только её включили в поставку единицы из производителей смартфонов, т.е. её практически нигде нет.

Это плохо. Но на том же Андроиде есть RenderScript, то по сути аналог и везде есть? Понятно что придется писать свой враппер, но это не проблема.

Ну час загруза не нужен, нужно где-то 200-500 мсек в минуту. Так что нагрузка будет пиковая и неравномерная. Ну или при полном загрузе, будет 2-3 сек на обработку документа, что реально для батареи не проблема, так как девайс будет для этого встроенный с кормлением от розетки.
А что мешает при таких расчётах просто использовать процессор? Сейчас почти все процессоры двуядерные и четырехядерная на мобильных устройствах. С таким же успехом можно посчитать на CPU.
Это плохо. Но на том же Андроиде есть RenderScript, то по сути аналог и везде есть? Понятно что придется писать свой враппер, но это не проблема.
У RenderScript API ещё не устаканилось, они постоянно его меняют. Да и я искренне сомневаюсь, что производители устройств (с их полугодичным циклом жизни) сильно заморачиваются, чтобы добавить туда поддержку GPU и DSP. Там скорей всего будет просто CPU.

Ну например Kernel-функция с плавающей точкой будет считать 15*15 точек на пиксел. Всего 5000*7000 пикселов. Тоесть, как минимум для того чтобы оно просчитало за секунду нужно 8Гигаитераций или где-то 40Гфлопс.

Тоесть, как минимум для того чтобы оно просчитало за секунду нужно 8Гигаитераций или где-то 40Гфлопс.
Тогда всё плохо, например, пиковая производительность PowerVR SGX 543MP2 на 300MHz (тот, который стоит в iPhone) 19Gflops, но она применима только для шейдеров, это не GPGPU. Нашумевшая Tegra3 — около 12Gflops, и тоже только для графических нужд. Четырёхядерный Mali-T604 на максимальных частотах в OpenCL показывает около 70 Gflops, если мне не изменяет память, то он стоит в Samsung Galaxy Note 10.1, чуть более продвинутый чип будет стоять в Google Nexus 10.
будет считать 15*15 точек на пиксел. Всего 5000*7000 пикселов
Опять же если на выходе после расчётов нужна картинка (текстура), то самое время изучать GLSL, тот что используется в OpenGL ES 2.0, и просто использовать шейдеры для рендеринга нужной картинки. OpenCL а такой задаче не особо и нужен. Это будет самый универсальный способ на сегодняшний день, но только для озвученной задачи.
Опять же если на выходе после расчётов нужна картинка (текстура)

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

Хотя с оптимизацией — 5Гфлопс должно хватить.

Тогда вот ещё один возможный show stopper: при render to texture существует очень ограниченный набор форматов текстур для рендеринга, самый большой это RGBA8888, 8 байт на цвет, т.е. если нужно будет хранить там float значения в цветовой компоненте, то это только через соответствующие расширения OpenGL ES 2.0, но их может и не быть. На сегодняшний день есть только одно расширение www.khronos.org/..._half_float.txt , которое позволяет рендерить в буфер у которого формат 16 бит half float на цветовой канал. Но если RGBA8888 хватит, то отлично.

Altera недавно вот OpenCL сделали для своих FPGA.

Підписатись на коментарі