AMV News

[Turbo]

Интересная статья, которая возможно поможет работать с видео намного быстрее:
http://habrahabr.ru/blogs/video/128751/
Для обладателей видеокарт от NVIDIA

[W_aZZa]

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

[Aggressor]

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

[vivan]

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

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

[Aggressor]

[W_aZZa]

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

[Aggressor]

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

[vivan]

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

Поэтому надеятся на адекватное сжатие на GPU (как видео, так и просто данных) смысла нет.

[Aggressor]

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

[vivan]

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

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

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

[W_aZZa]

[Aggressor]

[batareiko]

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

Я вообще не очень оптимистично смотрю на темп внедрения GPU вычислений.

[Aggressor]

[vivan]

[batareiko]

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

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

[Aggressor]

[vivan]

У интела OpenCL тоже может работать на проце. Даже, скорее, исключительно на нем
http://software.intel.com/en-us/articles/opencl-sdk-frequently-asked-questions/#9

[batareiko]

[Aggressor]

[batareiko]

[Aggressor]

Что-то мы чем глубже в лес, тем дальше от темы. Вернёмся к повестке дня.
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, то они бывают разные: есть стандартизированные Кронос груп, есть поставляемые всеми вендорами, и есть специфические для конкретного вендора. Пиши на стандартизированных, и будет тебе счастье.

Ну и по мелочи:

[batareiko]

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

[vivan]

[Aggressor]

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

[vivan]

и? Для сортировки нужен очень сложный алгоритм, требующий глубокого анализа?

[Aggressor]

А теперь вспомни, что сам же писал выше:

[vivan]

Cортировка без единого if'а.

[Aggressor]

[W_aZZa]

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