Применение GPGPU для сжатия аудио

В рекламе своих видеокарт NVIDIA и AMD частенько приводят возможность быстрого сжатия видео как наглядный пример полезности вычислительных возможностей GPGPU для рядового потребителя. Но об ускорении сжатия аудио с помощью GPGPU слышно гораздо меньше. Несколько лет назад NVIDIA объявляла конкурс на реализацию кодировщика mp3 с помощью технологии CUDA, но судя по отсутствию какой-либо информации о результатах конкурса, затея не удалась. Между тем, сама по себе идея ускорения сжатия аудио вполне реализуема, и актуальна для многих пользователей, тратящих массу времени на оцифровку своей коллекции компакт-дисков.

Я решил начать с анализа форматов сжатия звука без потерь (lossless), так как постоянное увеличение объёма носителей и удешевление дискового пространства уже сегодня позволяет не идти на компромиссы между экономией места и качеством звука. Идеальным кандидатом оказался популярный формат FLAC. Его главными достоинствами являются открытость стандарта и широкая аппаратная поддержка. Вдобавок он оказался удивительно хорошо приспособлен к параллельной обработке - в отличие от многих конкурирующих кодеков (ALAC, TTA...).

Первые же эксперименты показали перспективность этого начинания: буквально за пару дней удалось ускорить сжатие в некоторых режимах. Достичь же по настоящему впечатляющих результатов удалось только перенеся практически весь алгоритм, благо не очень сложный, на GPGPU, минимизировав обмен данных с видеокартой по шине PCIe. Новый flac-кодировщик, получившй название FlaCuda, сжимает быстрее чем стандартный flac в самом быстром режиме, при том что превосходит по сжатию flac в самом медленном режиме. Даже на такой скромной видеокарте, как NVIDIA GTS 250, скорость сжатия теперь лимитируется в основном скоростью жесткого диска.

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

Forums: 

Клево. А для расжатия - в

Клево.

А для расжатия - в FLAC разве нету точек синхронизации ? Судя по тому, что длинные треки играет с середины нормально - должны бы быть.

Ну так и разжимать первую минуту (условно) на первом ядре, вторую - на втором и так далее....

Не получится.

Там точки синхронизации, даже когда есть - то раз в 10 секунд аудио. Обычный многоядерный процессор таким образом еще можно было бы занять, поднапрягшись, но для эффективного использования GPGPU нужно чтобы параллельно работали тысячи нитей, причем на каждую отведено всего несколько ячеек быстрой памяти. Причем нити одного варпа (32 штуки) должны находиться всегда в одном и том же месте алгоритма, т.е. на первом же условном переходе (if или for) они перестали бы исполняться параллельно. В общем это попросту невозможно по целому ряду причин.

А если параллелиться только

А если параллелиться только по числу SM? Ну есть в 280-й 30 штук процессоров - пусть в 30 потоков и фигачит.
Тоже ведь хлеб....

"Жить то вы будете, а смысл..." (c)

Тактовая частота у GPGPU раза в 3 меньше чем у CPU, а такая базовая операция как целочисленное умножение например выполняется 8 тактов на GPGPU, когда на CPU если использовать SSE можно по 4 операции в такт выдавать... При таком раскладе оно хорошо еще если на 280й догонит CPU по скорости.

Если вы на CPU можете

Если вы на CPU можете использовать SSE, то и на GPU можно 4 треда параллельно запустить.

Про 32-битные целые - да, очень хочется обойтись 24-мя битами.

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