Можно ли использовать графический процессор мобильного устройства для ускорения сжатия изображений во время выполнения?

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

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

Было бы здорово, если бы существовало собственное расширение Flash, которое могло бы быстро сжимать динамически генерируемые изображения в форматы карт текстур GPU. Я предполагаю, что может потребоваться некоторая хитрость, например, использование графического процессора в процессе сжатия, чтобы сделать это за приемлемое время. Мой конкретный векторный арт-проект мог бы допустить простые методы сокращения цветовой палитры, такие как PVRTC4, что может быть? выполнимо в AS3.

Я работаю над проектом, который динамически генерирует большие карты текстур фона во время выполнения из векторов Flash, в проекте с использованием Starling (инструменты, которые позволяют смертным использовать GPU через stage3D). Было бы большим плюсом иметь возможность генерировать сжатые текстуры, которые занимают меньше памяти графического процессора, кажется, что единственным текущим решением для минимизации размера памяти текстурной карты является использование предварительно сжатых внешних изображений, таких как контейнер Adobe ATF. Хотя срок службы Flash, возможно, уже истек, я все еще могу получить файлы дистрибутива в 10 раз меньше, используя векторы flash вместо любого из методов сжатия растрового изображения с альфа-каналом.

Adobe добавила средство «Flash Player 11.4 и AIR 3.4 поддерживают сжатие текстур во время выполнения» (но оказывается, что в настоящее время оно работает только на настольных системах).

Упоминается в этой статье как дополнение: http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7d5b.html

Чтобы получить доступ к функциональным возможностям: «Создайте объект текстуры, вызвав метод Context3D.createTexture(), передав flash.display3D.Context3DTextureFormat.COMPRESSED».

Тема была поднята здесь: stackoverflow.com/questions/18070813/how-to-implement-the-runtime-compression-of-texture

Создатель скворца работал над включением средств сжатия изображений Adobe во время выполнения только для того, чтобы узнать от Adobe, что в настоящее время они не работают на мобильных устройствах. https://github.com/PrimaryFeather/Starling-Framework/issues/153

Я предполагаю, что для кого-то будет огромной проблемой создать код для сжатия формата PVRTC, ETC1 или DXT5 в зависимости от устройства, просто для поддержки нескольких генерируемых растровых изображений на лету.

Вот библиотека С++ "транскодирования в реальном времени", которая может быть актуальной:

code.google.com/p/crunch/

и перевод javascript: www-cs-students.stanford.edu/~eparker/files/crunch/more_info.html


person user3232559    schedule 19.02.2014    source источник
comment
Низкоуровневое программирование графического процессора нецелесообразно на большинстве платформ. OpenGL и D3D перешли исключительно на языки затенения высокого уровня, поскольку аппаратное обеспечение сильно различается между поколениями и поставщиками. Даже языки ассемблера, которые они когда-то раскрывали, не были такими уж низкоуровневыми, они были переведены драйвером в собственный набор инструкций графического процессора. В любом случае, вы знаете, что можете позволить драйверу выполнить сжатие, а затем вызвать glGetCompressedTexImage (...), чтобы прочитать его обратно, верно? Однако офлайн-сжатие часто бывает более качественным. OpenGL ES немного отличается, но ваш тег подразумевает настольную GL.   -  person Andon M. Coleman    schedule 20.02.2014


Ответы (1)


Я надеялся, что кто-то с реальным опытом ответит на этот вопрос... да ладно, поехали.

«Низкоуровневое программирование графического процессора» не такое уж и черное искусство. Вы пишете шейдеры на диалекте C. Вы можете выполнять маскирование битов и целочисленные сдвиги, а также математику с плавающей запятой. Самое сложное — понять, как GPU выполняет параллельную обработку и как данные передаются вашим шейдерам. Отправной точкой должна стать OpenGL SuperBible.

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

Надеюсь это поможет.

person Hugh Fisher    schedule 23.02.2014
comment
Педантичное замечание, более чем через два года после того, как всем было наплевать: мобильные графические процессоры, реализующие GLES 2.0, не обязательно могут изначально обрабатывать целые числа; разрешено эмулировать целые типы с типами с плавающей запятой. Следовательно, все побитовое является «зарезервированным» (подразумевается незаконным). Что касается «мобильной» части вопроса, вам, вероятно, нужно будет делать все, как с плавающей запятой, чтобы поразить все устройства, все еще находящиеся на рынке. См. khronos.org/files/opengles_shading_language.pdf §4.1.3 и §5.5. 1. ES 3.0 гарантирует подлинные целые числа (см. GLSL_ES_Specification_3.00.3.pdf по тому же URL-адресу). - person Tommy; 07.03.2016