Fastvideo

Часть 2: JPEG2000 в науке и медицине. Ограничения формата JP2

2021-01-13T19:24:43.097Z

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

JPEG2000 в науке и медицине

Поддержка window mode — одна из немаловажных особенностей, которая привлекает внимание к JPEG2000. Учёным нередко приходится работать с файлами просто огромного разрешения, ширина и высота которых могут превосходить 40 000 пикселей. Но интерес представляет лишь небольшая его часть. Привычному JPEG для работы с таким изображением пришлось бы декодировать его целиком, а JPEG2000 позволяет декодировать лишь выбранную область.

JP2 используется также и для съёмки в космосе. Все эти чудесные фотографии Марса, сделанные, например, на камеру HiRISE — его заслуга. Однако, канал передачи данных из космоса на Землю подвержен влиянию помех, поэтому при передаче могут появиться ошибки или даже могут быть потеряны целые пакеты данных. Рассматриваемый формат при включении специального режима устойчив к ошибкам, возникающим, когда устройства связи или хранения ненадежны. Такой режим позволяет производить коррекцию ошибок, возникающих при потере данных во время передачи. Достигается это следующим образом: сперва изображение делится на небольшие блоки (например, 32x32 или 64x64 пикселя), затем после предварительных преобразований каждая битовая плоскость кодируется отдельно. Таким образом, потерянный бит может испортить лишь одну битовую плоскость, а это обычно незначительно сказывается на качестве изображения в целом. К слову, у JPEG потеря бита может привести к полной непригодности части или даже всего изображения.

Самый первый снимок Марса в высоком разрешении от HiRISE (29 сентября 2006 года), оригинал здесь

О работе специального режима с проверкой на целостность информации в файле формата JPEG2000. В сжатый файл добавляется дополнительная информация, позволяющая проверить корректность данных. Без этой информации мы зачастую не можем определить при декодировании, есть ошибка или нет, и продолжаем процесс как ни в чём не бывало: в результате, всё ещё возможна ситуация, в которой даже один ошибочный бит портит достаточно большую часть картинки. А если такой режим включен, то мы обнаруживаем ошибку при её появлении и можем ограничить её влияние на другие части картинки.

Формат не остался незамеченным и в медицине. Здесь крайне важна поддержка такой разрядности исходных данных, которая бы позволила зафиксировать все тонкости цвета каждой изучаемой области нашего организма. JPEG2000 используется в томографии, рентгеновских снимках, МРТ, КТ и т.д. И все получаемые изображения обязаны в соответствии с требованием FDA (Food and Drug Administration) храниться в том виде, в котором были получены — без потерь. JPEG2000 идеально подходит для этой задачи.

Ещё одна интересная возможность JPEG2000 — сжатие трёхмерных массивов данных. Она может быть весьма актуальна как в науке, так и в медицине (например, трёхмерные результаты томографии). Сжатию таких данных посвящена 10-я часть стандарта JPEG2000: JP3D (volumetric imaging).

Ограничения формата JP2

К сожалению, с JP2 (JPEG2000) не все так просто — собственно, поэтому он практически не используется веб-браузерами (за исключением Safari). Формат является вычислительно сложным, и существующие кодеки с открытым исходным кодом на протяжении многих лет были слишком медленными для активного использования. Даже сейчас, когда скорость процессоров растет с каждым новым поколением, а кодеки оптимизируются и ускоряются, их возможности — всё ещё не предел мечтаний. Для иллюстрации важности скорости работы кодека вернёмся на минуту к разговору о цифровом кино. Конкретно — к созданию DCP (Digital Cinema Package) пакетов, того самого набора файлов, которым мы наслаждаемся в кинотеатрах. Напомним, что JPEG2000 является стандартом для цифрового кино, а, соответственно, необходим и для создания DCP-пакета. К сожалению, его вычислительная сложность делает данную задачу довольно ресурсоёмкой и затратной по времени. Более того, существующие кодеки с открытым исходным кодом не позволяют декодировать фильмы с требуемой частотой 25, 30 или 60 кадров в секунду для 12-битных данных при разрешениях уже в 2К или в 4К.

Можно ли работать с JPEG2000 быстрее?

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

Для ускорения работы с JPEG2000 мы в Fastvideo разработали свою реализацию кодека JPEG2000. В основе нашего решения лежит технология NVIDIA CUDA, благодаря которой стало возможным сделать параллельную реализацию кодера и декодера, задействовав все ядра CPU и GPU. В результате, наше решение работает намного быстрее аналогов и дает принципиально новые возможности пользователям. Мы верим, что наше решение позволит существенно ускорить работу с форматом тех, кто уже выбрал JP2, и приумножить их число. А, соответственно, и сделать качественные изображения куда более доступными для всех специалистов в областях, нуждающихся в оригинальном качестве.

#j2k

#jpeg2000

#cuda

#fastvideo

#cinema

Оригинал статьи: https://www.fastvideo.ru/blog/jpeg2000-applications-part2.htm

JPEG2000 в кино, науке, медицине и бродкастинге

2021-01-13T19:21:29.412Z

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

Часть 1: JPEG2000 в цифровом кино и телевещании. Особенности формата JP2

Мир кино покорил сердца людей сразу с момента своего появления. Все смеялись над фильмами Чарли Чаплина и ужасались Птицам Хичкока. От немого и чёрно-белого кино (вдумайтесь — всего чуть больше, чем за век) индустрия шагнула в мир IMAX. Изображение стало настолько чётким и живым, что мы моментально погружаемся в новую реальность, рисуемую автором на экране.

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

JP2 - это формат файлов для изображений, сжатых по алгоритму JPEG2000.

JPEG2000 в цифровом кино

В цифровом кино (и не только, но об этом позже) уже давно и активно используется формат JP2. Он был создан в 2000 году, а выбран в качестве стандарта для цифрового кино инициативной группой Digital Cinema Initiatives (DCI), в состав которой входили такие компании как Disney, Fox, Paramount, MGM, Sony Pictures Entertainment, Universal и Warner Bros. Studios, в 2004 году. В этом же году в первую часть стандарта JPEG2000 были внесены поправки посвященные цифровому кино.

Для цифрового кино хорошее сжатие было просто необходимым. Полуторачасовой фильм в разрешении 2К или 4K с разрядностью цветовых каналов 12 бит и частотой 24 кадр/с, сжатый с помощью JPEG2000 при стандартном битрейте в 250 Мбит/с, занимает в результате не более 160 гигабайт.

Алгоритм сжатия JPEG2000, благодаря которому мы можем наслаждаться прекрасным изображением в IMAX, основан на двух ключевых технологиях — дискретного вейвлет-преобразования (DWT) и встроенного блочного кодирования с оптимизированным усечением (EBCOT). У каждого из них своя важная роль:

DWT создает многомасштабное представление картинки для выделения пространственных и частотных компонент изображения. Это позволяет, например, просматривать фильм, сохранённый с разрешением 4K, в разрешении 2K;
EBCOT позволяет упорядочивать информацию о пикселях каждого кодируемого блока по важности, обеспечивая таким образом плавное ухудшение качества картинки при увеличении степени сжатия.

Особенности формата: 12 бит и опция сжатия без потерь

Итак, поговорим о JPEG2000, его особенностях и областях применения. Почему же картинка в JP2 такая сочная? Глубина цвета! Одним из практически важных достоинств формата является работа с данными большой битности. Проще говоря, он позволяет описывать один пиксель изображения, используя большее количество бит, чем может отображать монитор, не предназначенный для профессиональной работы с цветом, а, значит, и хранить больше информации о цвете. Сравните изображения в привычном JPEG (8 бит на канал) с изображением в уже упоминаемом IMAX, где используются 12-битные изображения. 8-битная картинка просто не способна передать такой диапазон цвета и яркости, как 12-битная, в результате качество изображения отличается принципиально.

Ещё одним немаловажным достоинством алгоритма JPEG2000 является соотношение между коэффициентом сжатия и качеством изображения (измеренным по любой метрике). От сжатия зависит, сколько будет "весить" файл, а, соответственно, и как быстро будет осуществляться его передача. Также от сжатия зависит и качество восстановленного изображения — наличие артефактов, согласитесь, никого не приводит в восторг.

Благодаря использованию вейвлетов (DWT) при высоких степенях сжатия изображения в JP2 не обзаводятся такими бросающимися в глаза артефактами, как у его предшественника JPEG — при сжатии проявляются границы квадратов 8x8 пикселей. Полностью артефактов избежать невозможно, но визуально они куда менее заметны. В результате, JPEG2000 позволяет сжимать изображения сильнее, а терять в качестве гораздо меньше, чем при таких же степенях сжатия позволяет JPEG. Более подробное сравнение JPEG2000 с JPEG вы можете найти в одной из наших статей.

Стоит отметить, что JPEG2000 позволяет в рамках одной архитектуры сжимать как с потерями (изображение становится чуть более размытым при восстановлении), так и математически без потерь. Изображение, в зависимости от его содержимого, можно сжать без потерь до 2,5 раз, сократив при этом объем занимаемой им памяти до 60%. Конечно, всегда есть исключения, и не всякое изображение можно сжать настолько и совсем без потерь. Однако, для многих фотографий это вполне достижимо. В любом случае, такие возможности сжатия очень востребованы везде, где требуется длительное время в сжатом виде хранить большой объем данных: документацию, изображения и видео с сохранением возможности восстановления без потерь. Например, в библиотеках, музеях и т.д.

Сжатие без потерь актуально в задачах, где выполняется или в будущем будет выполняться глубокий анализ изображения или многоэтапная обработка (а каждый их этап может вносить дополнительные потери); там, где небольшие детали, полученные на пределе чувствительности камеры, могут иметь большое значение. Примеры: диагностика заболеваний на ранней стадии, исследования нанообъектов и процессов на пределе чувствительности микроскопа, изучение очень далёких космических объектов и процессов.

JPEG2000 в цифровом телевещании

Продолжая разговор о сжатии, нельзя не сказать о спортивных трансляциях, например футбольных и баскетбольных матчей. Во время трансляции ещё не сжатое видео с камеры передается на специальную приставку, где происходит сжатие изображений JPEG2000. Далее, уже в формате JP2, они передаются на сервер, где вновь идет перекодировка для создания видео, подходящего для нашего с вами просмотра. В данном случае важны как быстрая передача изображений, так и сохранность его качества. В JPEG2000 используется, уже упоминаемое, кодирование EBCOT, которое позволяет выбирать порядок хранения разрешений, слоёв качества, цветовых компонент и позиций. Благодаря ему JPEG2000 поддерживает динамическое распределение качества. Другими словами, он позволяет автоматически регулировать объём передаваемых данных в зависимости от пропускной способности канала. Таким образом на сервера быстро поступают изображения максимально возможного качества для данного IP-канала.

Продолжение следует...

#j2k

#jpeg2000

#cuda

#fastvideo

Оригинальная статья: https://www.fastvideo.ru/blog/jpeg2000-applications-part1.htm

Как сделать цветокор через удалённый доступ?

2021-01-12T06:53:08.362Z

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

Теоретически, для работы колористу можно перевести всё необходимое оборудование на дом. Однако, по какой-то причине это может оказаться непрактичным, и вопрос об организации удаленной работы остальных ченов команды остается открытым. Более жизнеспособным решением, является организация удаленного доступа. В таком случае, каждому из команды пост-обработки необходимо иметь под рукой профессиональный монитор и компьютер с одной из программ для удалённой работы (TeamViewer, AnyDesk, Google Remote Desktop и т.д.) и доступ в интернет. Основная сложность при таком варианте заключается в передаче высококачественного изображения. Дело в том, что ни Skype, ни Zoom, ни другие программы для видеоконференций не поддерживают передачу 10-битных или 12-битных кадров.

Мы в Fastvideo создали свое решение для такого рода задач: приложениe Live Remote Color Grading. Оно не заменяет программы для удаленной работы или программы цветокоррекции (Blackmagic Davinci Resolve, Adobe Premiere Pro, AVID Media Composer, Baselight и т. д.), а работает вместе с ними и решает конкретные задачи: приема, кодирования, передачи, декодирования и визуализации изображений в высоком качестве там, где это требуется.

На левом мониторе изображение, полученное с помощью Live Remote Color Grading с удаленного PC, на правом работа на удаленном PC в программе цветокоррекции Davinci Resolve

Возможности софта

Программное обеспечение с низкой задержкой
Быстрая и надежная передача данных по внутренней или общедоступной сети
Быстрое получение и обработка потоков SD / HD-SDI и 3G-SDI (распаковка, упаковка, преобразование)
Кодирование и декодирование JPEG2000 (J2K) в реальном времени (с потерями или без потерь)
Высокое качество изображения
Точная цветопередача
Максимальная разрядность (10 или 12 бит на канал)

Как работает наше приложение? Подробно со всеми техническими моментами можно ознакомиться на нашем сайте в статье, посвященной удалённой цветокоррекции, где мы дали исчерпывающие рекомендации по аппаратному и программному обеспечению. В данной статье ограничимся рассмотрением базовой схемы работы нашего приложения:

Базовая схема работы софта и оборудования

Источник видео (видео в основной полосе частот) -> Устройство захвата (DeckLink) -> Распаковка SDI на графическом процессоре -> Кодер J2K на графическом процессоре -> Брандмауэр объекта (IPsec VPN) -> Общедоступный Интернет -> Удаленный межсетевой экран (IPsec VPN) - > Декодер J2K на GPU -> Упаковка SDI на GPU -> Устройство вывода (DeckLink) -> Отображение видео (видео в основной полосе частот)

Хотелось бы поделиться несколькими историями наших клиентов, уже оценивших удобство использования программы Live Remote Color Grading для удаленной цветокоррекции:

Одному из наших клиентов, колористу, в связи с Covid-19 пришлось уйти в оплачиваемый отпуск. Оставшись дома, он решил продолжить работу в своей сфере и стал брать заказы на удаленную цветокоррекцию. Его навыки оказались очень востребованными и ему пришлось вести несколько проектов одновременно. Более того, проекты были горящими и все корректировки, и согласования приходилось делать быстро и порой в режиме реального времени. Наше приложение позволило сделать этот процесс возможным и удобным как для колориста, так и для его заказчиков. Команды постобработки удаленно отсматривали вместе с ним получившийся материал и предлагала свои корректировки, которые колорист вносил по ходу просмотра и полученный результат сразу отображался у них на мониторах. Такой процесс позволил полностью избежать необходимости оффлайн встреч, к тому же позволил нашему клиенту вести несколько проектов одновременно и работать в привычных ему программах для цветокоррекции.

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

Как видно, наше приложение позволяет быстро внедрить удаленную цветокоррекцию в рабочий процесс без необходимости изучения новых программ для цветокоррекции или долгой настройки программного обеспечения. Для работы с ним достаточно обычного PC с видеокартой NVIDIA (необходима для работы Live Remote Color Grading), профессионального монитора и доступа к интернету. Стоит заметить, что существует ряд известных аппаратных решений для задачи удаленной цветокоррекции, такие как Nevion, Streambox, Sohonet. Они надежные, но очень дорогие. Решение Fastvideo требует для работы меньше оборудования, а предлагает такое же высокое качество, низкую задержку и меньшую стоимость. В результате вся команда постобработки без лишних затрат больше не будет привязана к конкретному месту, а для организации совместного просмотра картины и обсуждения спорных моментов достаточно иметь под рукой профессиональный монитор или TV поддерживающее высокую глубину цвета, домашний компьютер и интернет.

#jpeg2000

#j2k

#fastvideo

#cinema

Быстрая обработка изображений: GPU vs CPU

2021-01-07T10:57:20.517Z

I. Введение

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

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

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

II. Особенности алгоритмов быстрой обработки изображений

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

Локальность. Каждый пиксел вычисляется на основе ограниченного количества соседей.
Высокая способность к распараллеливанию. Каждый пиксел не зависит по данным от других обработанных пикселей, что позволяет распараллелить процесс обработки.
16/32-битная точность арифметики. Как правило, при обработке изображений достаточно 32-битной вещественной (floating point) арифметики для обработки и 16-битного целочисленного типа данных для хранения.

Критерии, которые важны для быстрой обработки изображений

Ключевыми критериями, важными для быстрой обработки изображений, являются:

1. Производительность

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

2. Качество обработки изображений

Еще одним важным критерием является качество обработки изображений. Для одной и той же операции обработки изображений может существовать несколько алгоритмов, отличающихся ресурсоёмкостью и качеством получаемого результата. И тут важно понимать, что обычно ресурсоёмкие алгоритмы дают более качественный результат. Таким образом, многоуровневая оптимизация наиболее востребована для ресурсоёмких алгоритмов. После её выполнения сложные алгоритмы могут выдавать результат за приемлемое время, сравнимое со временем работы изначально быстрого, но более грубого алгоритма.

3. Латентность

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

III. Ключевые отличия между GPU и CPU

1. Количество потоков на CPU и GPU

Архитектура центральных процессоров предполагает, что каждое физическое ядро на CPU может выполнять 2 потока вычислений при наличии 2 виртуальных ядер. В этом случае каждый поток выполняет инструкции независимо. В то же время количество потоков GPU в сотни раз больше, так как в этих процессорах используется программная модель SIMT (Single instruction, multiple threads). В этом случае группа потоков (обычно их 32) выполняет одну и ту же инструкцию. Таким образом, именно такую группу можно рассматривать в качестве эквивалента CPU потока, поэтому эту группу назвают истинным GPU потоком.

2. Способ реализации потоков на CPU и GPU

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

Из всего этого можно сделать вывод, что многие алгоритмы обработки изображений идеально подходят для реализации на GPU.

IV. Преимущества GPU над CPU

Наши лабораторные исследования показали, что при сравнении идеально оптимизированного софта для GPU и для CPU (с применением AVX2), преимущество GPU имеет глобальный характер: пиковые производительности CPU и GPU аналогичного года производства отличаются обычно на порядок для 32- и 16-битных типов данных. Также на порядок отличается и пропускная способность подсистемы памяти. В следующих пунктах мы рассмотрим эту ситуацию подробнее.
Если же использовать для сравнения софт для CPU без использования инструкций AVX2, то разница в производительности может достигать 50-100 раз в пользу GPU.
Все современные GPU оснащены разделяемой памятью, которая одновременно доступна всем «вычислителям» одного мультипроцессора, что, по сути, является программно-управляемым кэшем. Он идеально подходит для алгоритмов с высокой степенью локальности. Скорость доступа к этой памяти в несколько раз превосходит возможности L1 кэша CPU.
Ещё одной важной особенностью GPU по сравнению с CPU является то, что количество доступных регистров можно менять динамически (от 64 до 256 на один поток), тем самым позволяя снижать нагрузку на подсистему памяти. Для сравнения, в архитектурах x86 и х64 используется 16 универсальных регистров и 16 AVX регистров на один поток.
Наличие нескольких специализированных аппаратных модулей на GPU для одновременной работы над совершенно разными задачами: аппаратная обработка изображений (ISP) на Jetson, асинхронное копирование в GPU и обратно, вычисления на GPU, аппаратное кодирование и декодирование видео (NVENC, NVDEC), тензорные ядра для нейросетей, OpenGL, DirectX, Vulkan для визуализации.

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

Встраиваемые (embedded) приложения

Следует помнить и о таком типе задач, как встраиваемые решения. Здесь GPU уже конкурируют со специализированными устройствами, такими как FPGA (программируемая пользователем вентильная матрица) и ASIC (интегральная схема специального назначения). Основным преимуществом GPU перед прочими решениями является их существенно большая гибкость. Для отдельных встраиваемых решений GPU может быть серьёзной альтернативой, так как мощные многоядерные процессоры не проходят по допустимым требованиям к размеру и энергопотреблению.

V. Заблуждения пользователей и разработчиков

1. У пользователей нет опыта работы с GPU, поэтому они пытаются многое сделать на CPU

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

2. Многократное копирование данных на GPU и обратно "убивает" производительность

Среди пользователей и разработчиков существует и такое предубеждение относительно обработки изображений на GPU. И здесь, как оказалось, это тоже всего лишь неверная интерпретация, поскольку надёжным решением в этом случае является реализация всей схемы обработки на GPU в рамках одной задачи. Исходные данные могут быть скопированы на GPU, а обратно на CPU отдаются только результаты расчётов. Таким образом, все промежуточные данные остаются на GPU. Кроме того, копирования могут выполняться асинхронно, в одно и то же время с вычислениями над предыдущим кадром.

3. Размер разделяемой памяти составляет 96 кБайт на каждый мультипроцессор, что очень мало

Несмотря на малый размер разделяемой памяти GPU в 96 кБайт, при экономичном подходе к управлению разделяемой памятью, этого объёма может хватить в полной мере. Именно в этом и состоит суть оптимизации ПО для CUDA/OpenCL. То есть нельзя просто перенести код с CPU на GPU, не принимая во внимание все особенности архитектуры GPU.

4. Недостаточный размер глобальной памяти GPU для решения сложных задач

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

5. Библиотеки по обработке на CPU тоже используют параллельные вычисления

Действительно, у CPU есть возможности по параллельной работе в рамках векторных операций типа AVX и многопоточности (например, через OpenMP). Но в большинстве случаев распараллеливание происходит самым простым способом: каждый кадр обрабатывается в отдельном потоке, а сам код обработки одного кадра остаётся последовательным. Использование векторных инструкций сталкивается со сложностью написания и поддержки кода для разных архитектур, моделей процессоров и систем. Оптимизация кода в библиотеках конкретных вендоров, например, Intel IPP, находится на высоком уровне. Проблемы возникают тогда, когда нужный функционал отсутствует в библиотеках и приходится использовать сторонние открытые или проприетарные библиотеки, где оптимизация может отсутствовать.

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

Тем не менее, современные промышленные камеры генерируют видеопотоки очень высокой интенсивности, которые часто исключают возможность передачи данных для обработки по сети в облако, поэтому для обработки видеопотока с таких камер обычно используются локальные ПК. Компьютер, используемый для вычислений, должен обладать требуемой производительностью для обработки, и, что важно по сравнению с облачным подходом, его необходимо приобрести на начальных этапах реализации решения. Производительность решения зависит как от аппаратного, так и от программного обеспечения. При планировании решения следует учитывать и то, какое аппаратное обеспечение используется. Если удаётся обойтись широко распространёнными аппаратными средствами, проблем не возникает, и можно использовать любое программное обеспечение. Как только возникает необходимость использования более дорогого оборудования, цена единицы производительности начинает быстро увеличиваться и это создает предпосылки для использования оптимизированного ПО.

Задача обработки данных с промышленных видеокамер характеризуется постоянной нагрузкой. Уровень нагрузки определяется набором применяемых алгоритмов и количеством данных в единицу времени. Система обработки изображений должна быть рассчитана на начальных этапах проекта, чтобы с гарантированным запасом справляться с данной нагрузкой, иначе обработка без потери данных будет невозможна. Это является ключевым отличием от web-систем, где нагрузка неравномерна.

VI. Заключение

Итак, подводя итоги всего вышесказанного, мы приходим к следующим выводам.

1. GPU является прекрасной альтернативой CPU для решения сложных задач по быстрой обработке изображений.

2. Производительность оптимизированных решений для обработки изображений на GPU намного выше, чем на CPU. В качестве подтверждения мысли, мы предлагаем вам обратиться к другой статье из блога Fastvideo, в которой описаны бенчмарки на разных GPU для часто используемых алгоритмов обработки и сжатия изображений.

3. GPU обладает архитектурой, благодаря которой осуществляется параллельная обработка пикселов изображения, что, в свою очередь, приводит к сокращению времени обработки одного изображения (латентности).

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

5. GPU обладает необходимой гибкостью, высокой производительностью, низким энергопотреблением для того, чтобы конкурировать с узкоспециализированными решениями типа FPGA/ASIC для использования в мобильных и встраиваемых решениях.

6. Объединение возможностей CUDA/OpenCL и аппаратных тензорных ядер позволяет значительно увеличить производительность для задач с применением нейросетей.

Приложение №1
Сравнение пиковой производительности CPU и GPU на примере NVIDIA

Сравнение выполним на типе float (32-битный вещественный тип). Этот тип отлично подходит для обработки изображений. Оценивать производительность будем для одного ядра. В случае с CPU всё просто, речь идет о производительности одного физического ядра. Для GPU всё несколько сложнее. То, что принято называть у GPU ядром – это по сути своей АЛУ, или, в терминологии NVIDIA – SP (Streaming Processor). Реальными аналогом CPU ядра является стриминговый мультипроцессор (в терминологии NVIDIA, Streaming Multiprocessor, SMP). Количество стриминговых процессоров в одном мультипроцессоре зависит от семейства GPU. Например, видеокарты NVIDIA Turing содержат 64 SP в одном SMP, а у NVIDIA Ampere их 128. За каждый такт один SP может выполнять одну инструкцию FMA (Fused Multiply–Add). Инструкция FMA выбрана здесь для сравнения, так как она используется для реализации свёртки в фильтрах. Её целочисленный аналог называется MAD. Инструкция (один из вариантов) выполняет следующее действие: B=AX+B, где B – аккумулятор, накапливающий значения свёртки, A – коэффициент фильтра, X – значение пиксела. Сама по себе такая инструкция выполняет два операции: умножение и суммирование. Это даёт нам производительность за такт для SMP: Turing - 2*64 =128 FLOP, Ampere - 2*128 = 256 FLOP

Современные CPU обладают возможностью за каждый такт выполнять 2 инструкции FMA из набора AVX2. Каждая такая инструкция содержит 8 float операндов и соответственно 16 операций (FLOP). Итого, одно CPU ядро выполняет 2*16=32 FLOP за такт.

Чтобы перейти к производительности в единицу времени, нужно умножить количество инструкций за такт на частоту устройства. В среднем, частота GPU находится в диапазоне 1.5–1.9 ГГц, а CPU при нагрузке на все ядра имеет частоту 3.5–4.5 ГГц. Инструкция FMA из набора AVX2 является сложной для CPU. При её исполнении участвует большое количество устройств и сильно возрастает тепловыделение. Это приводит к тому, что CPU вынужден снижать частоту, чтобы избежать перегрева. Для разных семейств CPU величина снижения частоты разная. Например, по этой статье можно оценить снижение до уровня 0.7 от полной. Далее будем брать коэффициент 0.8, он соответствует более новым поколениям CPU.

Условно можно считать, что CPU по частоте в 2.5 раза быстрее GPU. С учётом коэффициента снижения частоты при работе с AVX2 инструкциями получим 2.5*0.8 = 2. Итого, относительная производительность в FLOP для инструкции FMA при сравнении с CPU ядром получим: Turing SMP = 128 / (2.0*32) = 2 раза, а для Ampere SMP это 256 / (2.0*32) = 4 раза, т.е. один SMP лучше, чем одно ядро CPU.

Оценим производительность L1 для CPU ядра. Современные СPU могут выполнять загрузку двух 256-битных регистров из кэша L1 параллельно или 64 байта за такт. GPU обладает унифицированным блоком SM/L1, здесь SM – Shared Memory. Производительность блока одинакова для двух архитектур и составляет 32 float за такт, или 128 байт за такт. Воспользовавшись соотношением частот, получим отношение производительностей 128 (байт за такт) / (2 (частота CPU больше GPU) * 64 (байт за такт)) = 1.

Также сравним размеры L1 и SM для CPU и GPU. Для CPU стандартным размером кэша данных L1 является 32 кБайт. Turing SMP имеет 96 кБайт унифицированного SM/L1 (64 кБайт за вычетом SM), а у Ampere SMP имеется 128 кБайт унифицированного SM/L1 (100 кБайт за вычетом SM).

Для оценки общий производительности определимся с количеством ядер на SP. Для настольных CPU рассмотрим вариант из 16 ядер (AMD Ryzen, Intel i9), у GPU (NVIDIA Quadro RTX 6000) имеется 72 SP. Итого отношение по количеству ядер 72/16 = 4.5. Таким образом, для этой пары CPU/GPU пропускная способность L1 и SM отличается в 1 * 4.5 = 4.5 раза.

На основе этого рассчитаем общую производительность по float. Для топовых видеокарт Turing получаем: 4.5 (отношение по количеству ядер GPU/CPU) * 2 (отношение производительности SMP к производительности одного ядра CPU) = 9 раз.
Для видеокарт Ampere получаем: 4.5 (отношение по количеству ядер GPU/CPU) * 4 (отношение производительности SMP к производительности одного ядра CPU) = 18 раз.

Мы получили численную оценку, которая отражает существенное преимущество GPU над CPU как по производительности, так и по скорости доступа к быстрой памяти в расчётах, связанных с обработкой изображений.

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

Скажем пару слов и о новым наборе AVX-512 для CPU. Это следующее поколение SIMD инструкций с увеличенной до 512 бит длиной вектора. Ожидается удвоение производительности в будущем по сравнению с AVX2. Современные версии CPU обеспечивают реальное преимущество до 1.6 раз, так как требуют ещё большего снижения частоты, чем инструкции из набора AVX2. Набор AVX-512 пока не получил широкого распространения в массовом сегменте, но это скорее всего произойдёт в будущем. Минусами этого подхода станут необходимость адаптации алгоритмов на новую длину вектора и перекомпиляция кода для поддержки.

Попробуем сравнить пропускную способность системной памяти. Тут тоже можно увидеть значительный разброс значений. Для CPU начальные цифры – это 50 ГБайт/с (2-канальный контроллер DDR4 3200) для массовых CPU. В сегменте для рабочих станций доминирует CPU с четырёхканальными контроллерами – это 100 ГБайт/с. Для серверов можно встретить CPU с 6-8 канальными контроллерами и производительностью более 150 ГБайт/с.

У GPU значение пропускной способности глобальной памяти тоже находится в широком диапазоне. Начиная от 450 ГБайт/с у модели Quadro RTX 5000, и заканчивая 1550 ГБайт/с у старшей модели A100. В итоге можно сказать, что пропускная способность в сопоставимых сегментах отличается значительно, вплоть до разницы на порядок.

Из всего вышесказанного можно сделать вывод, что GPU существенно (иногда практически на порядок) превосходит CPU, который выполняет оптимизированный код. В случае неоптимизированного для CPU кода, разница по производительности может быть ещё больше, до 50–100 раз. Все это создаёт серьёзные предпосылки для увеличения производительности в реальных задачах.

Приложение №2 - алгоритмы memory-bound и compute bound

Когда мы говорим об этих типах алгоритмов, необходимо понимать, что речь идёт о конкретной реализации алгоритма на конкретной архитектуре. У каждого процессора есть некоторая пиковая арифметическая производительность. Если реализация алгоритма может на целевом участке достигнуть пиковой производительности процессора по вычислительным инструкциям, то тогда она compute-bound, в противном случае основным ограничением станет память и реализация memory-bound.

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

Алгоритм может быть изначально compute-bound на первом уровне иерархии, а затем стать memory-bound на более высоких уровнях иерархии.

Рассмотрим несколько примеров. Допустим, мы хотим сложить два массива и записать результат в третий. Можно записать это как X = Y + Z, где X, Y, Z – массивы. Допустим, мы воспользуемся инструкциями AVX для реализации на процессоре. Тогда на один элемент нам потребуется два чтения, одно суммирование и одна запись. Современный CPU может выполнить два чтения и одну запись одновременно в кэш L1. Но вместе с тем, он может выполнить и две арифметические инструкции, а мы можем воспользоваться только одной. Это значит, что алгоритм суммирования массивов является memory-bound уже на первом уровне иерархии памяти.

Рассмотрим второй алгоритм. Фильтрация изображения в окне 3×3. Фильтрация изображения основана на операции свёртки окрестности пиксела с коэффициентами фильтра. Для вычисления свёртки используется инструкция MAD (или FMA в зависимости от архитектуры). Для окна 3×3 потребуется 9 таких инструкций. Операция инструкции B = AX + B, где B – аккумулятор, накапливающий значения свёртки, A – коэффициент фильтра, X – значение пиксела. Значения A и B находятся в регистрах, а значения пиксела загружаются из памяти. В этом случае на одну инструкцию FMA требуется одна загрузка. Здесь CPU сможет за счёт двух загрузок снабжать данными два порта FMA и полностью загрузит процессор. Алгоритм можно считать compute-bound.

Давайте рассмотрим этот же алгоритм на уровне доступа к оперативной памяти. Возьмём самую экономную по памяти реализацию, когда одно чтение пиксела обновляет все окна в которые он входит. В этом случае на одну операцию чтения будет приходиться 9 инструкций FMA. Таким образом, одно ядро CPU при обработке float данных на частоте 4 ГГц потребует 2 (инструкции за такт) × 8 (float в AVX регистре) × 4 (Байта в float) × 4 (ГГц) / 9 = 28.5 ГБайт/с. Двухканальный контролер с DDR4-3200 имеет пиковую пропускную способность в 50 ГБайт/с и по расчётам он способен быть источником данных только для двух CPU ядер в этой задаче. Поэтому такой алгоритм, запущенный на 8–16 ядерном процессоре является memory-bound. Несмотря на то, что на нижнем уровне он сбалансирован.

Теперь рассмотрим этот же алгоритм при реализации на GPU. Сразу видно, что GPU имеет на уровне SMP менее сбалансированную архитектуру с уклоном в вычисления. Для архитектуры Turing отношение скорости арифметических операций (во float) к скорости загрузки из Shared Memory – 2:1, для Ampere 4:1. За счёт большего количества регистров на GPU можно реализовать указанную выше оптимизацию для CPU напрямую на регистрах GPU. Это позволяет сбалансировать алгоритм даже для Ampere. И на уровне Shared Memory реализация остается compute-bound. С точки зрения памяти верхнего уровня (глобальной) расчёт для Quadro RTX 5000 (Turing) даёт следующие результаты: 64 (операций за такт) × 4 (Байт в float) × 1.7 (ГГц) / 9 = 48.3 ГБайт/с на один SMP. Отношение общей пропускной способности к пропускной способности SMP составит 450 / 48.3 = 9.3 раза. Общее количество SMP в Quadro RTX 5000 равно 48. Т.е. и для GPU алгоритм фильтрации на высоком уровне является memory-bound.

По мере роста размера окна алгоритм становится всё более сложным и соответственно смещается в сторону compute-bound. Большинство алгоритмов обработки изображений являются memory-bound на уровне глобальной памяти. И так как пропускная способность памяти GPU во многих случаях на порядок больше чем у CPU, то это обеспечивает сопоставимый прирост производительности.

Приложение №3
Программные модели SIMD и SIMT, или почему у GPU так много потоков

Для повышения производительности CPU используются SIMD (single instruction, multiple data) инструкции. Одна такая инструкция позволяет выполнить несколько однотипных операций над вектором данных. Плюсом этого подхода является рост производительности без существенной модификации instruction pipeline. Все современные CPU, как x86, так и ARM, имеют SIMD инструкции. Минусом данного подхода является сложность программирования. Основной подход к SIMD программированию — это использование intrinsic. Intrinsic – это встроенные функции компилятора, которые содержат одну или несколько SIMD-инструкций, плюс инструкции для подготовки параметров. Intrinsic формируют низкоуровневый язык, очень близкий к ассемблеру, который крайне трудоёмок в использовании. Кроме того, для каждого набора инструкций у каждого компилятора есть свой набор Intrinsic. Выходит новый набор инструкций – нужно всё переписывать, переходим на новую платформу (с x86 на ARM) нужно переписывать, переходим на другой компилятор - опять нужно всё переписывать.

Программная модель для GPU называется SIMT (Single instruction, multiple threads). Одна инструкция синхронно исполняется в нескольких потоках. Этот подход можно считать развитием SIMD. Скалярная программная модель скрывает векторную суть машины, автоматизируя и упрощая многие операции. Именно поэтому для большинства программистов писать привычный скалярный код на SIMT проще, чем векторный на чистом SIMD.

CPU и GPU по-разному решают вопрос латентности инструкций при исполнении их на конвейере. Латентность инструкции – это через сколько тактов следующая инструкция может воспользоваться её результатами. Например, если латентность инструкции равна 3 и CPU может запускать 4 таких инструкции за такт, то за 3 такта процессор запустит 2 зависимых инструкции или 12 независимых. Чтобы избежать такого существенного простоя, все современные процессоры используют внеочередное исполнение инструкций. В этом случае процессор в заданном окне CPU анализирует зависимости инструкций и запускает независимые инструкции вне очереди.

GPU использует другой подход, основанный на многопоточности. У GPU есть pool потоков. Каждый такт выбирается один поток и из него выбирается одна инструкция, которая отправляется на исполнение. На следующем такте выбирается следующий поток и так далее. После того, как из всех потоков в pool была запущена одна инструкция, возвращаемся к первому потоку и т.д. Такой подход позволяет скрыть латентность зависимых инструкций за счёт исполнения инструкций из других потоков.

При программировании GPU можно условно выделить два уровня потоков. Первый уровень потоков отвечает за формирование SIMT. Для GPU NVIDIA – это 32 соседних потока, которые называются warp. Известно, что SMP для Turing поддерживает 1024 потока. Это количество распадается на 32 настоящих потока, в рамках которых организуется SIMT исполнение. Настоящие потоки могут в один момент времени исполнять разные инструкции, в отличие от SIMT.

Таким образом, стриминговый мультипроцессор Turing – это векторная машина с размером вектора 32 и 32-мя независимыми потоками. Ядро CPU с AVX – это векторная машина с размером вектора 8 и двумя независимыми потоками.

Дополнительные материалы по теме

Функционал Fastvideo SDK для обработки и сжатия изображений на NVIDIA GPU

Бенчмарки по обработке и сжатию изображений для разных моделей платформы NVIDIA Jetson

Оригинальная статья: https://www.fastvideo.ru/blog/cpu-vs-gpu-fast-image-processing.htm

Бенчмарки производительности для Jetson Nano, TX1, TX2, AGX Xavier

2021-01-05T10:56:44.219Z

Бенчмарки производительности для Jetson Nano, TX1, TX2, AGX Xavier

Компания NVIDIA выпустила серию аппаратных модулей Jetson для встраиваемых приложений. NVIDIA ® Jetson-это ведущая в мире встраиваемая платформа для обработки изображений и задач DL/AI. Эта платформа позволяет делать высокопроизводительные вычисления при минимальном энергопотреблении для глубокого обучения и компьютерного зрения, что крайне востребовано для мобильных вычислительных проектов.

Мы разработали SDK для обработки изображений и видео для NVIDIA Jetson. Здесь мы представляем результаты тестов производительности для различных модулей. В качестве тестового конвейера обработки изображений мы рассмотрим стандартное приложение для обработки данных от камер машинного зрения.

Benchmarks: https://www.fastvideo.ru/pub/2021/Fastvideo_SDK_benchmarks.pdf

Аппаратные возможности модулей Jetson Nano, TX1, TX2, AGX Xavier

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

В приложениях для видео камер мы обычно можем скрыть передачу данных от хоста к устройству с помощью режима zero-copy или благодаря перекрытию копирований и вычислений на GPU. Передача данных от устройства к хосту может быть скрыта с помощью перекрытия копирований / вычислений.

Аппаратные и программные модули для тестирования

CPU/GPU NVIDIA Jetson Nano, TX1, TX2/TX2i, AGX Xavier
OS L4T (Ubuntu 18.04)
CUDA Toolkit 10.2 for Jetson Nano, TX2/TX2i, AGX Xavier
Fastvideo SDK 0.16.1

Сравнение модулей NVIDIA Jetson: Nano, TX1, TX2, AGX Xavier

Для этих модулей NVIDIA Jetson мы провели измерения производительности для следующих стандартных задач обработки изображений, специфичных для приложений с промышленными видеокамерами: баланс белого, демозаика (дебайер), цветокоррекция, ресайз, кодирование JPEG и т.д. Это не полный набор имеющихся функций из Fastvideo SDK - это просто пример того, какую производительность можно получить для каждого Jetson. Кроме того, тестовое приложение gpu-camera-sample можно загрузить с GitHub, собрать и сделать измерения производительности для вашей схемы обработки данных.

Время обработки (kernel time) на GPU для кадров 2K (1920×1080, 8/16-бит), в миллисекундах

Общее время обработки вычисляется для значений из серых строк таблицы. Это сделано для того, чтобы показать как возможности SDK, так и максимальный результат для каждого модуля Jetson. Приведенная схема обработки является упрощённой, но, тем не менее, она используется в реальных приложениях с промышленными видеокамерами.

Здесь мы сделали оценку времени работы только базового набора модулей обработки изображений из Fastvideo SDK, чтобы разработчики решений на платформе Jetson могли понять, какую производительность обработки они могут получить в своих приложениях. Преобразование изображений из RAW в RGB или из RAW в JPEG - это стандартные задачи, которые возникают в разных областях. Теперь разработчики могут заранее получать подробную информацию об ожидаемой производительности для выбранного конвейера в соответствии с приведенной выше таблицей. В сравнение пока не вошли кодек JPEG2000 для сжатия изображений, а также кодеры и декодеры Jetson H. 264 и H.265 (мы скоро их тоже добавим). Тут важно, что кодеры H.264 и H.265 работают на аппаратном уровне, т.е. кодирование можно будет выполнять параллельно с кодом на CUDA - это снизит нагрузку на видеокарту, а в некоторых случаях можно будет получить еще более высокую производительность.

Мы провели те же измерения времени ядра для графических процессоров NVIDIA GeForce и Quadro. Здесь можно скачать документ с результатами тестов.

Программное обеспечение для тестирования модулей Jetson

Для приложений с промышленными камерами мы разработали программное обеспечение для NVIDIA Jetson и оно доступно для загрузки c Github как в виде бинарных файлов, так в исходных кодах (пример gpu-camera-sample). Этот проект может работать на Windows 7/10, Linux Ubuntu 18.04 и L4T, т.е. не только с Jetson, но и с любыми другими видеокартами NVIDIA. Помимо реализации полного конвейера обработки изображений на графическом процессоре, реализованы опции онлайн-сжатия и потоковой передачи видео, измерения glass-to-glass (G2G) для оценки реальной задержки для камерных систем на Jetson. В настоящее время программное обеспечение работает с камерами машинного зрения XIMEA, Basler, JAI, Matrix Vision и Daheng Imaging.

Для тестирования этого программного обеспечения даже не обязательно иметь видеокамеру, т.к. в нём реализована возможность работы с RAW кадрами с диска, т.е. без участия камеры. Таким образом, можно измерить скорость обработки данных, а также оценить качество.

Чтобы проверить производительность Fastvideo SDK на графическом процессоре ноутбука/настольного компьютера/сервера без какого-либо программирования, также можно скачать программное обеспечение Fast CinemaDNG Processor с графическим интерфейсом для Windows или Linux. Это программное обеспечение имеет окно тестов производительности, и там вы можете увидеть измеренное время для каждого этапа обработки изображений. Этот метод тестирования производительности вообще не требует программирования от пользователя, а конвейер обработки изображений в этом случае может быть довольно сложным - таким образом можно проверить и скорость, и качество. Также можно проверсти различные тесты на изображениях с различным разрешением, чтобы увидеть, насколько производительность зависит от размера изображения, его содержимого и других параметров.

Адрес оригинальной статьи: https://www.fastvideo.ru/blog/jetson-performance-comparison.htm

#jetson

Fastvideo

Часть 2: JPEG2000 в науке и медицине. Ограничения формата JP2

JPEG2000 в науке и медицине

Ограничения формата JP2

Можно ли работать с JPEG2000 быстрее?

JPEG2000 в кино, науке, медицине и бродкастинге

Часть 1: JPEG2000 в цифровом кино и телевещании. Особенности формата JP2

JPEG2000 в цифровом кино

Особенности формата: 12 бит и опция сжатия без потерь

JPEG2000 в цифровом телевещании

Как сделать цветокор через удалённый доступ?

Возможности софта

Базовая схема работы софта и оборудования

Быстрая обработка изображений: GPU vs CPU

I. Введение

II. Особенности алгоритмов быстрой обработки изображений

Критерии, которые важны для быстрой обработки изображений

1. Производительность

2. Качество обработки изображений

3. Латентность

III. Ключевые отличия между GPU и CPU

1. Количество потоков на CPU и GPU

2. Способ реализации потоков на CPU и GPU

IV. Преимущества GPU над CPU

Встраиваемые (embedded) приложения

V. Заблуждения пользователей и разработчиков

1. У пользователей нет опыта работы с GPU, поэтому они пытаются многое сделать на CPU

2. Многократное копирование данных на GPU и обратно "убивает" производительность

3. Размер разделяемой памяти составляет 96 кБайт на каждый мультипроцессор, что очень мало

4. Недостаточный размер глобальной памяти GPU для решения сложных задач

5. Библиотеки по обработке на CPU тоже используют параллельные вычисления

VI. Заключение

Приложение №1Сравнение пиковой производительности CPU и GPU на примере NVIDIA

Приложение №2 - алгоритмы memory-bound и compute bound

Приложение №3Программные модели SIMD и SIMT, или почему у GPU так много потоков

Дополнительные материалы по теме

Бенчмарки производительности для Jetson Nano, TX1, TX2, AGX Xavier

Бенчмарки производительности для Jetson Nano, TX1, TX2, AGX Xavier

Аппаратные возможности модулей Jetson Nano, TX1, TX2, AGX Xavier

Аппаратные и программные модули для тестирования

Сравнение модулей NVIDIA Jetson: Nano, TX1, TX2, AGX Xavier

Время обработки (kernel time) на GPU для кадров 2K (1920×1080, 8/16-бит), в миллисекундах

Программное обеспечение для тестирования модулей Jetson

Приложение №1
Сравнение пиковой производительности CPU и GPU на примере NVIDIA

Приложение №3
Программные модели SIMD и SIMT, или почему у GPU так много потоков