Распараллеливаемое сжатие в формате jpeg с использованием только DCT, этапы кодирования длин серий, какой тип сжатия / производительности возможен? - PullRequest
3 голосов
/ 18 сентября 2010

Нам нужно сжать тонну (монохромные) данные изображения и быстро их переместить. Если бы нужно было просто использовать распараллеливаемые этапы сжатия jpeg (DCT и кодирование длины прогона квантованных результатов) и запустить его на GPU, чтобы каждый блок сжимался параллельно, я надеюсь, что это будет очень быстро и при этом даст очень значительный коэффициент сжатия, как у полного jpeg.

Кто-нибудь с большим опытом сжатия графических процессоров / изображений имеет представление о том, как можно сравнить как сжатие, так и производительность по сравнению с использованием libjpeg на процессоре? (Если это глупая идея, не стесняйтесь говорить об этом - я очень новичок в своих знаниях cuda и различных этапах сжатия JPEG.) Конечно, это будет меньше сжатия и, надеюсь, (?) Быстрее, но я понятия не имею, как Значительными могут быть эти факторы.

1 Ответ

0 голосов
/ 28 сентября 2010

Вы вряд ли сможете получить большее сжатие в графическом процессоре - просто нет достаточно сложных алгоритмов, которые могли бы использовать эту МНОГО мощность.

При работе с простыми alos, такими как JPEG, - это так просто, что вы будете тратить большую часть времени на передачу данных через шину PCI-E (что имеет значительную задержку, особенно когда карта не поддерживает передачи DMA).

Положительным моментом является то, что если у карты есть DMA, вы можете освободить процессор для более важных вещей и получить сжатие изображений «бесплатно».

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

...