The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен быстрый упаковщик текстур ETC2

19.09.2016 11:42

Инженеры из компаний Google и Blue Shift опубликовали открытую реализацию упаковщика текстур на базе алгоритма сжатия ETC2 (Ericsson Texture Compression), обеспечивающего высокую эффективность сжатия при сохранении качества исходного изображения. Формат ETC2 включён в стандарт OpenGL ES 3 и не требует выплаты отчислений за использование запатентованных технологий. Код распространяется под лицензией Apache 2.0.

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

Для того, чтобы ощутить насколько назрела необходимость появления быстрого упаковщика можно привести следующие сведения: наиболее популярный упаковщик Mali GPU Texture Compression tool в среднем тратит около 640 секунд (10 минут) на одну текстуру. В типичной игре на базе движка Unity поставляется от 500 до 1500 текстур, т.е. на упаковку всех текстур уходит от 3 до 12 дней. В ситуации приложений для работы с виртуальной реальностью объём текстур и время на их упаковку увеличивается в 2-4 раза.

Новый упаковщик тратит на сжатие текстуры в среднем 10 секунд, т.е. работает в 64 раза быстрее упаковщика Mali. Подобного ускорения удалось добиться благодаря тонким настройкам режимов работы, многопоточной архитектуре и реализации упорядоченного поиска блоков с учётом их типов (ETC2 разбивает изображение на блоки 4x4, каждый блок может быть 10 типов, что для картинки 1024x1024 требует выбора оптимального варианта из 10⁶⁵⁵³⁶ комбинаций).



  1. Главная ссылка к новости (https://medium.com/@duhroach/b...)
  2. OpenNews: Разработчики Intel добавили поддержку сжатия текстур ETC2 в Mesa
  3. OpenNews: Компания Intel интегрировала в Mesa поддержку OpenGL ES 3.0 и начала сертификацию Mesa в Khronos Group
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: etc2, texture, compress, image
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (38) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:03, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Огласите пожалуйста список патентов?
     
     
  • 2.4, llolik (ok), 15:34, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Формат ETC2 включён в стандарт OpenGL ES 3 и не требует выплаты отчислений за использование запатентованных технологий

    вроде как, в статье написано. Догадываюсь, что Khronos Group.

     
     
  • 3.5, Аноним (-), 15:53, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    клоун: Не требует выплат, но это не означает отсутствия иных ограничений.
     
     
  • 4.9, Аноним (-), 20:19, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да нет там никаких особых ограничений. MS таки додавится жабой вместе с эпплом. И рулить в результате будет вулкан, тогда как DX12 и Metal - ну вы поняли. Благо вулкан даже на андроиде работать будет.
     
     
  • 5.16, Аноним (-), 21:47, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Назови 5 игр класса ААА за последние 5 лет, которые вышли на Vulkan, но не вышли на DirectX, пожалуйста.
     
     
  • 6.17, Ю (?), 22:03, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А теперь почитай когда Вулкан вышел!!!
     
  • 6.19, XoRe (ok), 00:12, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Назови 5 игр класса ААА за последние 5 лет, которые вышли на
    > Vulkan, но не вышли на DirectX, пожалуйста.

    Первый выпуск vulkan: 16 февраля 2016 г.
    Лишь бы пи**нуть...

    Можно ведь дурацкие аргументы и в обратную сторону поворачивать - была ли у DirectX портируемость на андроид в первые пол года после выхода первой версии?
    Что, тогда не было андроида? Ну, вы первый начали требовать дебильные вещи :)

     
     
  • 7.24, Аноним (-), 12:05, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    клоун: не слежу, не знал. Но даже полгода большой срок чтобы уже что-то вышло. И где?
     
     
  • 8.25, Аноним (-), 13:11, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    З Ы если бы было написано клоун, - тогда это типа обращение к оппоненту н... текст свёрнут, показать
     
     
  • 9.27, Аноним (-), 14:44, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    offtopic Ты что первый день на OpenNET offtopic ... текст свёрнут, показать
     
     
  • 10.36, Аноним (-), 17:14, 21/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    какой-то профессиональный юмор ... текст свёрнут, показать
     
  • 8.26, Цыган (?), 13:18, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    DOOM 2016 И СКОРО НА ЕГО ДВИЖКЕ quake И Т Д ... текст свёрнут, показать
     
     
  • 9.28, Аноним (-), 14:48, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Но как же Денуво ... текст свёрнут, показать
     
  • 8.37, marks (?), 20:37, 22/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дум Хотя это довольно предсказуемо, если вспомнить политику id И нет, полгода... текст свёрнут, показать
     
  • 7.31, Аноним (-), 16:46, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > у DirectX портируемость на андроид в первые пол года после выхода
    > первой версии?

    Ее у DX нету и спустя цать лет :). Как максимум можно приклеить на скотч прослойку, но прослойки дурят и на писюках то а на андроиде будет совсем вешалка. Там железо странное и слабое, с прослойками можно будет вволю посношаться и пожалуй написать оптимизированный рендерер на вулкане может оказаться проще.

     
  • 6.30, Аноним (-), 16:44, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Назови 5 игр класса ААА за последние 5 лет, которые вышли на
    > Vulkan, но не вышли на DirectX, пожалуйста.

    Я лучше скажу что вулкану едва полгода а рендереры под него сделали уже и поболее чем 5 AAA игр. Почти все новые игры идут с вулканом. При том они поюзают линь как testbed, а потом по мере появления вулкана в ведроиде - просто перенесут игры и туда.

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

    А за сколько можно сделать драйвер вулкана иллюстрирует RADV - опенсорсный вулкан для GCNов. Ему наверное месяц, его пилят 2 человека между делом. А он уже доту запускает. У которой есть рендерер на вулкане. Есть ли в доте рендерер DX12 - вот это я не знаю. Хотя-бы потому что у меня нет винды.

     
  • 5.23, Аноним (-), 05:25, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > DX12

    Судя по спецификациям это спи***ный Vulkan. Но судя по всему они это и не скрывают.

     

  • 1.2, анон (?), 14:13, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Mali GPU Texture Compression tool в среднем тратит около 640 секунд (10 минут) на одну текстуру.

    Еще бы описали, что за процесс такой сложный и зачем он нужен в итоге.

     
     
  • 2.3, A.Stahl (ok), 14:45, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    ETC2 разбивает изображение на блоки 4x4, каждый блок может быть 10 типов, что для картинки 1024x1024 требует выбора оптимального варианта из 10⁶⁵⁵³⁶ комбинаций
     
     
  • 3.6, Аноним (-), 18:10, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Что-то подобное было в id Tech 5. Только называлось MegaTexture и появилось раньше этого.
     
     
  • 4.12, Аноним (-), 20:22, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что-то подобное было в id Tech 5. Только называлось MegaTexture и появилось
    > раньше этого.

    Вообще разные технологии. ETC это непатентованный вариант вещей типа STC/DXTC/... - т.е. сжатия. А мегатекстуры в doom - просто блоки текстур. К сжатию мегатекстуры не относятся никак, просто более быстрый (по мнению автора движка) способ адресации.

     
     
  • 5.20, Аноним (-), 04:52, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А мегатекстуры в doom - просто блоки текстур.

    Вообще-то там тоже используется сжатие. Учите матчасть.

    https://en.wikipedia.org/wiki/Id_Tech_4#MegaTexture_rendering_technology

    В русской версии есть картинка даже https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B3

    [зануда]
    Это было до Doom ещё в Rage =)
    [/зануда]


     
     
  • 6.29, Аноним (-), 15:33, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    вообще-то в QUAKE wars, до Rage
     
  • 2.10, Аноним (-), 20:20, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Еще бы описали, что за процесс такой сложный и зачем он нужен в итоге.

    Для сжатия текстур. Сжатые текстуры занимают меньше VRAM чем несжатые. А если так получилось что текстуры не влезли в VRAM - догружать их из внешней памяти раз в 10 медленнее. Как тебе идея получить в сцене 6FPS вместо 60? С сжатием текстур - текстуры могут быть получше а просадки - пореже :)

     
     
  • 3.21, Аноним (-), 04:59, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как тебе идея получить в сцене 6FPS вместо 60?

    Кратковременная просадка. В зависимости от программиста и железа вы можете как не заметить её так и наблюдать слайдшоу в течении нескольких секунд. Заметьте, что почти во всех играх с отрытым миром - мир рисуется чанками, то есть блоками 100х100 например, а остальные блоки прогружаются по мере вашего продвижения по "миру". Вообще-то RAM довольно быстрая и так как VRAM ещё быстрее, то удалить один массив и записать другой для неё не составит труда, единственное, что может её остановить - слабый процессор.

     
     
  • 4.32, Аноним (-), 17:32, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это зависит от того насколько сильно не хватает видеопамяти Можно и постоянный ... текст свёрнут, показать
     

  • 1.7, Аноним (-), 18:18, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    клоун: чё-то какую-то фигню прогнали.

    По сути работает тот же принцип, что и в формате DjVu: изображение разбивается на небольшие блоки, каждый из которых сжимается своим алгоритмом. Есть перечень поддерживаемых алгоритмов и программы-архиваторы, напр. Mali.

    В зависимости от целей, можно настроить Mali сжимать всё одним алгоритмом, выбирать наиболее сильное сжатие из всех алгоритмов или указать размер допустимой деградации качества (напр. JPEG с 65% качеством и JPEG с 90% качеством сильно различаются по размеру и качеству). Если выбрать наилучшее сжатие при макс. 10% потерь качества, то каждую текстуру придётся пересжать всем чем можно чтобы сравнить и выбрать лучшее. 10 минут для такой задачи - это вполне нормальное время.

    Недавно в список стандартов попал новый формат сжатия - ETC2. В ближайшем релизе он будет включён (а может и уже включён) в состав Mali.

    > ускорения удалось добиться благодаря тонким настройкам режимов работы

    Вот в это верю. Программа с тюнингом обгонит ту же программу в стандартной поставке если сравнивать их в синтетическом тесте.

    > работает в 64 раза быстрее упаковщика Mali

    А вот в это не верю. Чтобы получить такую дикую разницу в производительности, разработчики Mali должны были неслабо накосячить.

    В новости в одну кучу свалили новый алгоритм сжатия ETC2 и его реализацию. В сравнении тяжёлого с кислым победил Google.

     
     
  • 2.11, А (??), 20:21, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > клоун: чё-то какую-то фигню прогнали.

    фигню здесь прогнал ты. ETC2 это стандарт, а Mali GPU Tool и эта программа — его реализации. И 10 минут на сжатие "достаточно всем" только сами знаете где.

     
  • 2.13, Аноним (-), 20:29, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А чего бы гуглю и не побеждать? Гугль нанял себе немало специалистов по сжатию данных и алгоритмам. Хорошее сжатие в GL ES? А они в андроиде этим пользуются. Это делает их систему лучше. На ней на тех же ресурсах можно запустить игры с более хорошим качеством картинки и при том не залетая на выплаты всяким вымогателям.

    У гугла есть и специалисты по сжатию в духе LZ для более обычных данных, с уклоном на вебстраницы. Они запилили формат сжатия Brotli который жмет почти как LZMA а скорость распаковки - как у zlib. Уже есть модули для нжинкса и апача, уже поддерживается хромом. Поэтому те кто пользуется опенсорсом и продуктами гугля - уже в плюсе: сайты грузятся быстрее при прочих равных. Меньше данных качается. Иногда - в разы.

    У гугля есть спецы по сжатию видео. AV1/AOM - это 70% гугловский VP10, 20% daala и остальное по мелочи - вкрапления технологий из цисковского thor и что там еще. Реально коммитит в основном гугл. Иногда мозилла. В порядке исключения есть пара чуваков из цыски. Ну а ms крутая и технологичная компания - оказывает моральную поддержку. Тем что хотя-бы не мешает :).

     
     
  • 3.15, Аноним (-), 21:46, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    клоун: Какое отношение всё это имеет к обсуждаемой теме?

    Есть:
    1. алгоритмы сжатия, стандартизированные в OpenGL, один из которых ETC2
    2. программа-архиватор Mali, реализующая ETC2 и ещё десяток других алгоритмов
    3. безымянная программа-архиватор от Google, реализующая только ETC2

    Что с чем сравнивалось и с какими настройками что была получена 64-кратная (!) разница?

    Что изображено на графике? Я вижу два алгоритма со сложностями O(1) и O(N^2). Такое бывает когда оптимизированную сортировку сравнивают с поплавком, но когда коммерческий продукт, который держит 90% этого рынка сравнивают с программой, у которой даже нет имени...

     
     
  • 4.33, Аноним (-), 17:37, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > клоун: Какое отношение всё это имеет к обсуждаемой теме?

    Самое непосредственное: гугл и тут нанял пару толковых парней под свои задачи.

    > 2. программа-архиватор Mali, реализующая ETC2 и ещё десяток других алгоритмов

    Да это ее проблемы. Если кому не западло ждать в 64 или сколько там раз дольше - они в своем праве.

    > Что изображено на графике? Я вижу два алгоритма со сложностями O(1) и
    > O(N^2). Такое бывает когда оптимизированную сортировку сравнивают с поплавком,

    Ну так если гугл может написать "оптимизированную сортировку" в своей области - это хорошо и правильно. А такие как ты могут вопить о том что ваш поплавок это круто до упупения. На винде все алгоритмы как-то так и работают в результате: оптимизации у виндовозов не в почете. Вот прям начиная с операционки, про состояние дел в которой недвусмысленно писал виндовый же разработчик. Разработчика потом стерли, но джинн из бутылки вылез и обратно уже не того :).

     

  • 1.8, абвгдейка (ok), 20:09, 19/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > JPEG с 65% качеством и JPEG с 90% качеством сильно различаются по размеру и качеству

    по размеру, но не по качеству :)

     
     
  • 2.14, Аноним (-), 21:39, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    клоун: от картинки зависит. Возьми белую картинку с чёрными полосами: белая полоса в 1 пкс, чёрная полоса в 1 пкс. Пережми её в PNG, JPG 65, JPG 90 и зацени разницу.
     
     
  • 3.18, абвгдейка (ok), 23:14, 19/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в разы.
     
     
  • 4.22, Аноним (-), 05:15, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в
    > разы.

    Заметишь, при 65% jpeg - мыло, только что проверил в GIMP. Причём некоторые полоски слились. Не думал, что это скажу когда-нибудь, но Клоун тут прав.

     
  • 4.34, Аноним (-), 17:39, 20/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в разы.

    Жпег - для изображений типа фотографий, с градиентами. PNG - для line art и прочей computer-generated графики типа скриншотов с большими однородными площадями.

    Как ни странно даже такой деград как клоун про это в курсе. Те кто этого не знал - должны просто устыдиться своего ламерства. Быть глупее клоуна... ух, это даже круче чем быть посланным на...й!

     
     
  • 5.35, Аноним (-), 09:13, 21/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Быть глупее клоуна.

    Он не глупый, он просто тролль.

     

  • 1.38, Аноним (-), 19:33, 23/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь в Mesa смогут запилить поддержку перекодирования на лету из кучи форматов в один прекрасный ETC2?
    И станет всё быстрее и не нужно будет покупать видеокарты с большим объёмом видеопамяти?
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру