AMV News
Музыкальные аниме клипы
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход  

CUDA в Adobe (Premiere и After Effects) CS5
На страницу 1, 2  След.
 
Начать новую тему   Ответить на тему    Список форумов AMV News -> Создание AMV
Предыдущая тема :: Следующая тема  
Автор Сообщение
Turbo



Пол: Пол:Муж
Возраст: 42
Администратор
Рега: 15.03.2006
Сообщения: 4303
Откуда: Зеленоград
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 10:07 am    Заголовок сообщения: CUDA в Adobe (Premiere и After Effects) CS5 Ответить с цитатой

Интересная статья, которая возможно поможет работать с видео намного быстрее:
http://habrahabr.ru/blogs/video/128751/
Для обладателей видеокарт от NVIDIA
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Youtube
W_aZZa



Пол: Пол:Муж
Возраст: 38
Заядлый
Рега: 18.06.2008
Сообщения: 2059
Откуда: Менск

СообщениеДобавлено: Вт Сен 20, 2011 10:23 am    Заголовок сообщения: Ответить с цитатой

Turbo
Ага, тоже читал. Про включению любой видеокарты с поддержкой CUDA известно уже давно. У самого nvidia, но сколько не думал, так и не придумал зачем мне это нужно Sad.
Больше подходит тем, кто работает с живым видео, которое снимает сам. Чтобы сразу без тормозов работать с видео с камеры без перекодирования.
Эффективность такой работы с анимешками в mp4 вроде никто не проверял. Да и наложение эффектов в премьере будет полезным только без последующего перехода в АЕ.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 1:01 pm    Заголовок сообщения: Ответить с цитатой

Премьерщику может пригодиться для эффектов, но это пока глюкозавр такой, как многоядерность в АЕ. Лучше бы в х264 добавили поддержку OpenCL. Rolling Eyes
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 5:25 pm    Заголовок сообщения: Ответить с цитатой

И что там в иксе с openCL делать?)

В общем это все актуально только для нескольких фифектов в премьере. В декодировании это никак не поможет (да даже если брать сразу видео в avc - то проц в несколько раз быстрее его декодирует. Правда в монтажках какие-то фиговые декодеры - это уже другой вопрос).
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 5:30 pm    Заголовок сообщения: Ответить с цитатой

vivan писал(а):
И что там в иксе с openCL делать?)
Кодировать, конечно, с использованием GPGPU. Если провести аналогию с трёхмерками, то ускорение может быть фантастическим, в 10-100 раз. А проприетарный API должен отсохнуть как можно скорее. Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
W_aZZa



Пол: Пол:Муж
Возраст: 38
Заядлый
Рега: 18.06.2008
Сообщения: 2059
Откуда: Менск

СообщениеДобавлено: Вт Сен 20, 2011 5:50 pm    Заголовок сообщения: Ответить с цитатой

Aggressor
Не думаю, что получить ускорение хотя бы в 2 раза будет так просто. Всё же написание под GPU весьма специфично и не все алгоритмы легко на него переносятся, а тем более с огромным ускорением.
Что мы можем распараллелить? Кадры - нет, они должны кодироваться последовательно. Поиск векторов движения - каждому ядрышку видюхи необходимо будет передавать чуть ли не целые кадры, а у них нет столько быстрой памяти Sad.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 5:54 pm    Заголовок сообщения: Ответить с цитатой

W_aZZa
Мы можем разделить картинку на блоки 16х16 и кодировать отдельно каждый. Да, не все конвееры загрузятся, если видяха мощная, а разрешение не очень большое, но прирост будет капитальный. К слову, не знаю, как сейчас, а два года назад в х264 многопоточность была реализована делением картинки на количество доступных ядер процессора с последующей сборкой в одно целое.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 6:09 pm    Заголовок сообщения: Ответить с цитатой

Aggressor,
GPU - это не просто какая-то магическая мощная железка Smile
Cуть в том, что GPU - это сотня китайцев. Глупых, но их дофига.
Эти шейдеры могут выполнять одинаковый код на разных наборах данных. Поэтому перемножить кучу матриц (рендеринг 3D) - легко, а вот какой-нибудь элементарный поиск - фиг вам.
Любое сжатие - это поиск избыточности. Поиск - это ветвление, а с ним у видях вообще никак (если грубо говоря - есть один if и если хоть в одном потоке условие выполнится, то все остальные потоки будут проставивать пока тот поток будет выполнять то что в if'e).
http://habrahabr.ru/blogs/hi/125398/

Поэтому надеятся на адекватное сжатие на GPU (как видео, так и просто данных) смысла нет.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 6:21 pm    Заголовок сообщения: Ответить с цитатой

vivan
Я имею представление об архитектуре GPU, и даже на чуть более глубоком уровне. Тебе кинуть ссылочку на рабочие кодировщики в H.264 с GPU-акселерацией, или сам нагуглишь? Wink
Кстати, ты ведь обладатель видяхи от ATI (я теперь тоже). В CCC есть фича, которая позволяет закодить видеофайлик с помощью видяхи, хотя я сам не пробовал и не знаю, во что именно.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 6:37 pm    Заголовок сообщения: Ответить с цитатой

Ага. Куча костылей и уровень ultrafast ~ superfast. Причем, самое забавное - x264 с таким пресетом выдает и примерно ту же скорость.

У меня еще есть ноут с SB, там QuickSync, который хоть и бесполезен чуть более чем полностью - но хотя бы качество чуть повыше.

А вообще у интела есть шансы.
1) с ними работает Dark Shikari (но под NDA, так что ничего не расскажет)
2) в SB GPU и CPU на одном кристалле, в теории скорость обмена данным между ними должна быть выской, и если GPU что-нибудь и может ускорить, то только при такой связке.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
W_aZZa



Пол: Пол:Муж
Возраст: 38
Заядлый
Рега: 18.06.2008
Сообщения: 2059
Откуда: Менск

СообщениеДобавлено: Вт Сен 20, 2011 6:45 pm    Заголовок сообщения: Ответить с цитатой

Aggressor писал(а):
Мы можем разделить картинку на блоки 16х16 и кодировать отдельно каждый.

Ну а теперь представь видео, где каждый блок 16 на 16 закодирован отдельно друг от друга. Задолбаемся компенсировать блочность.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 6:48 pm    Заголовок сообщения: Ответить с цитатой

vivan писал(а):
Куча костылей и уровень ultrafast ~ superfast.
А ты хотел, чтоб сразу было как в сказке? Скорее дело в том, что никому не охота этим заниматься, т.к. затраты времени на кодирование несопоставимы с тем же трёхмерным рендерингом.
Соглашусь, что полностью перенести процесс на GPU не выйдет (в том виде, в каком оно существует на данный момент), но перегрузить какие-то ресурсоёмкие задачи вполне можно. Например, пока ты тут пытаешься меня убедить, что это невозможно, мой знакомый перекодирует в Nero очередной фильм, чтобы посмотреть его через DVD-плеер на телеке, и его старенькая видяха ускоряет процесс в 4 раза.

W_aZZa писал(а):
Ну а теперь представь видео, где каждый блок 16 на 16 закодирован отдельно друг от друга. Задолбаемся компенсировать блочность.
В превью разрешение ~320х170, и на 8 процессах (четырёхядерник с гипертредингом) мы получим лоскутки не намного большего размера. Я не вижу никаких проблем. Хотя повторюсь, что не знаю, изменилось ли что-то в этом плане в х264 за то время, что я перестал интересоваться его внутренностями.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
batareiko



Пол: Пол:Муж

Местный
Рега: 18.05.2009
Сообщения: 1279

СообщениеДобавлено: Вт Сен 20, 2011 6:54 pm    Заголовок сообщения: Ответить с цитатой

Не стоит прельщаться на слово Open в названии OpenCL. Во-первых декларируемая открытость никак не соотносится с качеством (а им занимается все та же печально известная Khronos Group), во-вторых там открытым является только стандарт, а его реализации не менее проприетарны чем тот же DirectMath. В-третьих драйвера OpenCL у ATI такие же дрянные, как и их ССС и его GPU - кодировщик (да, он действительно шустро выдает H.264 видео, но оно будет закодировано с использованием только базовых методов, битрейт буде завышен, и при этом с артефактами, не говоря о банальных вылетах).

Я вообще не очень оптимистично смотрю на темп внедрения GPU вычислений.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 7:03 pm    Заголовок сообщения: Ответить с цитатой

VirtualTT писал(а):
Во-первых декларируемая открытость никак не соотносится с качеством
Одно с другим вообще никак не соотносится, и не должно. Да и оно ведь новорожденное почти, CUDA его намного старше.

VirtualTT писал(а):
во-вторых там открытым является только стандарт, а его реализации не менее проприетарны чем тот же DirectMath.
Что есть «его реализации», поясни? В OpenCL нету ничего проприетарного по определению.

VirtualTT писал(а):
В-третьих драйвера OpenCL у ATI такие же дрянные
Это информация какого года? Обнови базу знаний, сейчас ATI в OpenCL разрывают nVidia как тузик грелку. В разы за те же деньги, без преувеличений.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 7:17 pm    Заголовок сообщения: Ответить с цитатой

Aggressor писал(а):
Например, пока ты тут пытаешься меня убедить, что это невозможно, мой знакомый перекодирует в Nero очередной фильм, чтобы посмотреть его через DVD-плеер на телеке, и его старенькая видяха ускоряет процесс в 4 раза.
Можно. Можно например качественный поиск векторов заменить на "сравнить с 9 блоками и выбрать лучший", если качественный поиск просто невозможно реализовать. Это не адекватное решение, которое не приведет к адекватному результату.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
batareiko



Пол: Пол:Муж

Местный
Рега: 18.05.2009
Сообщения: 1279

СообщениеДобавлено: Вт Сен 20, 2011 7:48 pm    Заголовок сообщения: Ответить с цитатой

OpenCL - это только стандарт, то бишь набор спецификаций без какого-либо воплощения в программном обеспечении или железе (так же, как и OpenGL). А собственно сделанные на его основе решения вовсе не обязаны быть открытыми, и в большинстве таковыми не являются.

А к драйверам ATI / AMD у меня вообще куча претензий, начиная хотя бы с того что у меня без ССС который только тормозит и немерено жрет память, на одном из мониторов начинаются проблемы с разверткой (изображение сжимается и висит по центру). Заявленная поддержка OpenGL 3.3 в моем радеоне 3870 - наглая ложь, даже 3.1 не работает. Собственно с OpenCL одна из проблем заключается в использовании разнородных устройств с некоторым набором аппаратных возможностей у каждого. Соответственно если GPU хотя бы по одному из параметров не соответствует требованиям приложения, то он не будет задействован. На деле выясняется что мой GPU с точки зрения OpenCL почти ни на что не способен, причем не потому что в нем аппаратно чего-то не хватает (хотя признаю, что мой R600 уже морально устарел), а потому что в драйверах это не реализовано. Информация где-то на начало этого года, и я сомневаюсь что в AMD с тех пор рьяно занимались реализацией полноценной поддержки устаревающих GPU...
Как мне кажется, одна из сильных сторон новых DirectX (начиная с 10) - это гарантированная аппаратная поддержка всех их функциональности, в т.ч. в области GPGPU вычислений. Соответственно ситуации когда видеокарта формально поддерживает DirectСompute, а на деле ничего не может - исключается.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 8:18 pm    Заголовок сообщения: Ответить с цитатой

vivan писал(а):
Это не адекватное решение, которое не приведет к адекватному результату.
Это рабочее решение, которое решает поставленную задачу быстрее конкурирующих. Человек пользуется и доволен.

VirtualTT писал(а):
OpenCL - это только стандарт, то бишь набор спецификаций без какого-либо воплощения в программном обеспечении или железе
Это в первую очередь открытый API, во вторую язык программирования. Я не могу понять, о каких решениях ты говоришь.

VirtualTT писал(а):
А к драйверам ATI / AMD у меня вообще куча претензий
У меня тоже есть несколько, только к OpenCL они не относятся.

VirtualTT писал(а):
Собственно с OpenCL одна из проблем заключается в использовании разнородных устройств с некоторым набором аппаратных возможностей у каждого. Соответственно если GPU хотя бы по одному из параметров не соответствует требованиям приложения, то он не будет задействован.
Враньё. Если видеокарта поддерживает OpenCL нужной версии, то абсолютно весь функционал, который можно запрограммировать, будет работать на ней. С разной скоростью от модели к модели.

VirtualTT писал(а):
На деле выясняется что мой GPU с точки зрения OpenCL почти ни на что не способен, причем не потому что в нем аппаратно чего-то не хватает (хотя признаю, что мой R600 уже морально устарел), а потому что в драйверах это не реализовано.
Как раз потому, что в нём аппаратно чего-то не хватает. Старые карты вообще слабо совместимы с GPGPU. Глупо обвинять OpenCL при такой железяке.

VirtualTT писал(а):
и я сомневаюсь что в AMD с тех пор рьяно занимались реализацией полноценной поддержки устаревающих GPU...
Кому нужны устаревающие GPU? Можно подумать, nVidia усиленно поддерживает свои старые карточки. Их слегка устаревшие профессиональные решения вроде quadro сейчас по производительности CUDA уступают геймерским современным, и это нормальная ситуация.

А ещё OpenCL работает не только на видеокарте, но и на процессоре (пока только AMD). Т.е. программист пишет один код, и он исполняется на всех доступных OpenCL-устройствах, что есть огромный плюс по сравнению с CUDA.

По личному опыту могу сказать, что замена GTS250 на HD6950 дала прирост производительности OpenCL в 18 раз. Это практическая скорость (рендеринг), а не тесты.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Вт Сен 20, 2011 8:23 pm    Заголовок сообщения: Ответить с цитатой

У интела OpenCL тоже может работать на проце. Даже, скорее, исключительно на нем Very Happy
http://software.intel.com/en-us/articles/opencl-sdk-frequently-asked-questions/#9
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
batareiko



Пол: Пол:Муж

Местный
Рега: 18.05.2009
Сообщения: 1279

СообщениеДобавлено: Вт Сен 20, 2011 9:33 pm    Заголовок сообщения: Ответить с цитатой

Aggressor писал(а):
Это в первую очередь открытый API, во вторую язык программирования. Я не могу понять, о каких решениях ты говоришь.
Этот API и язык описаны на бумаге. А то что работает на компьютере - это собственно и есть "решения". И ни о какой открытости реализации этих решений речи не идет. Например исходники инструментария и библиотек поставляемых в AMD APP SDK или драйверов AMD, и уж тем более особенности аппаратной реализации поддержки OpenCL никто раскрывать не собирается.

Aggressor писал(а):
Враньё. Если видеокарта поддерживает OpenCL нужной версии, то абсолютно весь функционал, который можно запрограммировать, будет работать на ней. С разной скоростью от модели к модели.
У вычислительных устройств OpenCL в рамках одной версии стандарта функционал может быть очень даже различным. Собственно это естественно, так как OpenCL предназначен для работы в гетерогенных системах. Вот краткое описание OpenCL, первый абзац - собственно определение что такое есть OpenCL, и на этой же странице справа нехилый список всяких категорий для характеристик и поддерживаемого функционала совместимых устройств. Особенно интересен последний пункт - device extensions. В свое время точно так же пилили OpenGL (да и сейчас пилят). Стандарт вроде как один, но куча самопальных решений и костылей от разных вендеров(от ATI, от NVidia и пр) которые добавляют в следующую версию стандарта. Вот познавательная статья История противостояния OpenGL и Direct3D - там очень адекватно описывается история развития OpenGL. Сейчас все все делается примерно в том же духе, только вендеров в развитии стандарта участвует больше(там же и Intel).

Aggressor писал(а):
Глупо обвинять OpenCL при такой железяке.
У этой железяки есть полная аппаратная поддержка DirectX10.1, у fireGL версии с этим чипом поддержка OpenCL вроде как полноценная. Никаких причин для неработоспособного OpenCL кроме недописанных драйверов тут нет. Да что тут OpenCL, даже заявленная поддержка для OpenGL 3.3 не работает.

Aggressor писал(а):
А ещё OpenCL работает не только на видеокарте, но и на процессоре (пока только AMD).
OpenCL вообще работает практически на любом CPU, и даже не только на x86-совместимых.

Aggressor писал(а):
По личному опыту могу сказать, что замена GTS250 на HD6950 дала прирост производительности OpenCL в 18 раз. Это практическая скорость (рендеринг), а не тесты.
В каких же приложениях такой колоссальный прирост производительности?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Вт Сен 20, 2011 11:24 pm    Заголовок сообщения: Ответить с цитатой

vivan писал(а):
У интела OpenCL тоже может работать на проце.
Блин, а у меня не запустилось. )

VirtualTT писал(а):
Например исходники инструментария и библиотек поставляемых в AMD APP SDK или драйверов AMD, и уж тем более особенности аппаратной реализации поддержки OpenCL никто раскрывать не собирается.
Аппаратная реализация совершенно из другой оперы, железо ведь должно быть конкурентоспособным. Зато день, когда вдруг SDK станет платным или доступным по подписке корпоративным клиентам, для OpenCL не настанет. Между тем слухи о том, что в новых геймерских карточках от nVidia будет урезан CUDA-функционал, ходят на зарубежных форумах уже сейчас. Они ведь со своим детищем вообще могут сделать что захотят и в любой момент.

VirtualTT писал(а):
У вычислительных устройств OpenCL в рамках одной версии стандарта функционал может быть очень даже различным.
Вот как раз это значения не имеет: когда ты пишешь на OpenCL, ты не обращаешься к устройству, ты обращаешься к абстрактному OpenCL device. А уж распихиванием запросов между гетерогенными железяками (CPU, GPU, etc.) займутся драйвера. Компиляция кернела на конкретной системе происходит в момент первого запуска приложения.

VirtualTT писал(а):
Никаких причин для неработоспособного OpenCL кроме недописанных драйверов тут нет.
Не верю. Точнее, я не верю, что драйвера недописаны просто так. Наверняка есть причина, например, производительность OpenCL будет ниже CPUшной. Опять же, OpenCL есть новый стандарт. Ты ведь не жалуешься, что твоя видяха не держит DirectX 11.

VirtualTT писал(а):
В каких же приложениях такой колоссальный прирост производительности?
SmallLuxGPU. На данный момент ещё два рендера обзаводятся поддержкой OpenCL, оба появятся в этом году.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
batareiko



Пол: Пол:Муж

Местный
Рега: 18.05.2009
Сообщения: 1279

СообщениеДобавлено: Ср Сен 21, 2011 9:08 pm    Заголовок сообщения: Ответить с цитатой

Aggressor писал(а):
Аппаратная реализация совершенно из другой оперы, железо ведь должно быть конкурентоспособным. Зато день, когда вдруг SDK станет платным или доступным по подписке корпоративным клиентам, для OpenCL не настанет.
-_-'' Открытость стандарта означает что это товарищам из AMD / Nvidia / Intel и пр не приходится раскошеливаться за его использование (в отличие от допустим h264). А SDK и сопутствующие инструменты они вольны выпускать как им заблагорассудится. То, что SDK распространяется бесплатно никак не является показателем его открытости. Тот же Windows SDK бесплатен, но ведь речи об открытости Windows не идет. Да и платные услуги и дополнительный инструментарий для этих SDK никто не отменял.

Aggressor писал(а):
Вот как раз это значения не имеет: когда ты пишешь на OpenCL, ты не обращаешься к устройству, ты обращаешься к абстрактному OpenCL device. А уж распихиванием запросов между гетерогенными железяками (CPU, GPU, etc.) займутся драйвера.
Это непосредственно в кернеле ты обращаешься к абстрактному устройству (и даже не к устройству, а к исполнителю "worker", проще говоря к потоку исполенения). Но программы использующие OpenCL состоят не из одних кернелов, а по большей части из управляющего кода который обязан заниматься инициализацией устройств, определением их пригодности для использования для конкретных кернелов, формированием очереди заданий (кернелов) для контекста конкретного устройства, отправкой и приемом данных с него и контролем за выполнением в целом. Короче говоря суть в том, что кернел можно написать отдельно, где выполнять его определяет непосредственно программа во время исполнения, а фреймворк OpenCL непосредственно обеспечивает работу кернела на выбранном целевом устройстве. Никакого волшебного "распихивания запросов между гетерогенными железяками (CPU, GPU, etc.)" они не осуществляют - это все надо делать самому. Причем даже для одинаковых GPU устройств надо будет в явном виде распределять задачи между ними (да-да никакого Cross-Fire). Что уж тут говорить про совместную работу GPU и CPU...

Aggressor писал(а):
Компиляция кернела на конкретной системе происходит в момент первого запуска приложения.
Кернелы могут распространятся и в бинарной форме. Они компилируются не в то, что будет исполнятся непосредственно на GPU, CPU или каком другом устройстве, а в управляющие команды для фреймворка.

Aggressor писал(а):
Не верю. Точнее, я не верю, что драйвера недописаны просто так. Наверняка есть причина, например, производительность OpenCL будет ниже CPUшной. Опять же, OpenCL есть новый стандарт. Ты ведь не жалуешься, что твоя видяха не держит DirectX 11.
Aggressor писал(а):
Между тем слухи о том, что в новых геймерских карточках от nVidia будет урезан CUDA-функционал, ходят на зарубежных форумах уже сейчас. Они ведь со своим детищем вообще могут сделать что захотят и в любой момент.
Это вообще обычное дело, ведь в карточках линейки FirePro с этим же чипом (и даже с еще более младшими) OpenCL работает, а для линейке радеона реализовать поддержку не удосуживаются.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Чт Сен 22, 2011 10:40 am    Заголовок сообщения: Ответить с цитатой

Что-то мы чем глубже в лес, тем дальше от темы. Вернёмся к повестке дня.
GPGPU в общем — на сегодня одно из самых перспективных направлений для существенного ускорения любых ресурсоёмких операций. Однако пока существующие решения для кодирования видео не подходят для АМВ-мейкеров ввиду низкого качества сжатого материала.
CUDA vs OpenCL — The NVIDIA CUDA Driver API allows programmers to develop applications for the CUDA architecture and is the predecessor of OpenCL. (nVidia OpenCL JumpStart guide, p. 2). И самое главное, OpenCL работает не только на видеокартах nVidia. Не думаю, что имеет смысл дальше об этом спорить.
Гетерогенность устройств OpenCL — Code is portable across various target devices:
– Correctness is guaranteed
– Performance of a given kernel is not guaranteed across differing target devices
(Illinois UPCRC Summer School 2010, The OpenCL Programming Model). Что касается device extentions, то они бывают разные: есть стандартизированные Кронос груп, есть поставляемые всеми вендорами, и есть специфические для конкретного вендора. Пиши на стандартизированных, и будет тебе счастье.

Ну и по мелочи:
VirtualTT писал(а):
Никакого волшебного "распихивания запросов между гетерогенными железяками (CPU, GPU, etc.)" они не осуществляют - это все надо делать самому.
Попробуй создать контекст из двух девайсов сразу и удивись.

VirtualTT писал(а):
Что уж тут говорить про совместную работу GPU и CPU...
CPU может одновременно являться хостом и девайсом, в этом нет ничего сверх. Кстати, упомянутый уже рендер SmallLuxGPU имеет тестовый модуль LuxMark, который рендерит тестовые сцены одновременно на CPU+GPU через OpenCL.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
batareiko



Пол: Пол:Муж

Местный
Рега: 18.05.2009
Сообщения: 1279

СообщениеДобавлено: Чт Сен 22, 2011 5:07 pm    Заголовок сообщения: Ответить с цитатой

Вообще CUDA от OpenCL в плане написания кода отличается лишь в деталях.

Aggressor писал(а):
Что касается device extentions, то они бывают разные: есть стандартизированные Кронос груп, есть поставляемые всеми вендорами, и есть специфические для конкретного вендора. Пиши на стандартизированных, и будет тебе счастье.
А для вендеров счастье когда пишут задействуя их расширения, тем самым вынуждая конечных пользователей покупать свои устройства.

Aggressor писал(а):
Попробуй создать контекст из двух девайсов сразу и удивись.
А вот и не удивлюсь. Контекст обеспечивает возможность совместного доступа к памяти для работающих в нем девайсов.
Твоя очередь удивляться: попробуй для этих двух девайсов создать очередь команд...
... и убедись что очередь команд можно создать только для одного устройства. Вот наглядный слайд от AMD. Или можешь обратиться к спецификации OpenCL (стр 46). имя редактора там многообещающее...

Aggressor писал(а):
Гетерогенность устройств OpenCL — Code is portable across various target devices:
– Correctness is guaranteed
– Performance of a given kernel is not guaranteed across differing target devices
Тут вполне ясно говорится об обеспечении выполнения кернелов на разных устройствах (пусть и с переменным успехом), но вот откуда взялась уверенность, что OpenCL самостоятельно распределяет нагрузку между ними - непонятно. Никакого "распихивания запросов между гетерогенными железяками" OpenCL не обеспечивает - эта задача ложится исключительно на плечи програмиста.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Чт Сен 22, 2011 5:55 pm    Заголовок сообщения: Ответить с цитатой

Aggressor писал(а):
для существенного ускорения узкого класса ресурсоёмких задач
скорее как-то так.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Чт Сен 22, 2011 8:24 pm    Заголовок сообщения: Ответить с цитатой

Теперь это тред по программированию на OpenCL. Smile

VirtualTT писал(а):
А для вендеров счастье когда пишут задействуя их расширения, тем самым вынуждая конечных пользователей покупать свои устройства.
Ничто не мешает делать сколько угодно версий хоть под каждую конкретную видеокарту, но я это сказал к тому, что проблема неработающего кода надумана.

VirtualTT писал(а):
Тут вполне ясно говорится об обеспечении выполнения кернелов на разных устройствах

VirtualTT писал(а):
Собственно с OpenCL одна из проблем заключается в использовании разнородных устройств с некоторым набором аппаратных возможностей у каждого. Соответственно если GPU хотя бы по одному из параметров не соответствует требованиям приложения, то он не будет задействован.
Что и требовалось доказать. Видяхи, как ни крути, крепко похожи друг на друга архитектурно, так что правильные экстеншны — и выполняемость кода на любом целевом девайсе обеспечена.

VirtualTT писал(а):
но вот откуда взялась уверенность, что OpenCL самостоятельно распределяет нагрузку между ними - непонятно.
А ты пролистай выше и посмотри, в каком контексте эта фраза вообще всплыла. Жаль, конечно, что очереди придётся создавать разные, но сути изначального вопроса это не меняет.

vivan писал(а):
скорее как-то так.
Это если лень или руки из спины. А у продвинутых людей уже сейчас вот так (сортировка же!). Wink
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Чт Сен 22, 2011 9:19 pm    Заголовок сообщения: Ответить с цитатой

и? Для сортировки нужен очень сложный алгоритм, требующий глубокого анализа? Very Happy
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Пт Сен 23, 2011 11:31 am    Заголовок сообщения: Ответить с цитатой

А теперь вспомни, что сам же писал выше:
vivan писал(а):
а вот какой-нибудь элементарный поиск - фиг вам.

И вспомни, что сортировка = поиск + куча if + перестановка. Профит!
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
vivan



Пол: Пол:Муж

Постоянный гость
Рега: 20.03.2009
Сообщения: 460
Откуда: Спб
Страна: Россия

СообщениеДобавлено: Пт Сен 23, 2011 4:32 pm    Заголовок сообщения: Ответить с цитатой

Cортировка без единого if'а.
Код:
for (int i = 0; i < n-1; i++)
  for (int t = 0; t < n-i-1; t++)
  {
    int a = arr[t];
    int b = arr[t+1];
    arr[t] = ((a + b) + abs (a - b)) / 2;
    arr[t+1] = ((a + b) - abs (a - b)) / 2;
  }
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Aggressor



Пол: Пол:Муж

Модератор
Рега: 07.03.2007
Сообщения: 2343
Откуда: Киев

СообщениеДобавлено: Пт Сен 23, 2011 5:23 pm    Заголовок сообщения: Ответить с цитатой

vivan писал(а):
int i = 0; i < n-1; i++
Жонглируешь операторами? А i < n-1 тебя, значит, не смущает? Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
W_aZZa



Пол: Пол:Муж
Возраст: 38
Заядлый
Рега: 18.06.2008
Сообщения: 2059
Откуда: Менск

СообщениеДобавлено: Пт Сен 23, 2011 7:50 pm    Заголовок сообщения: Ответить с цитатой

Открывайте уже отдельную тему >_>.
В OpenCL разрешены ветвления и циклы, чо спорить то? Проблемма же не в "ифах", а возможных преимуществах при перенесении задачи на множество потоков. А спорить тут нечего, класс задач узковат для GPU. И дело не в условиях или циклах. Некоторые алгоритмы получают минимальное преимущество при параллельном выполнении, т.к. быстрее самой длинной ветки алгоритма всё равно не получится вычислить.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Начать новую тему   Ответить на тему    Список форумов AMV News -> Создание AMV Часовой пояс: GMT + 3
На страницу 1, 2  След.
Страница 1 из 2

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы можете добавлять приложения в этом форуме
Вы можете скачивать файлы в этом форуме