Инженеры из компаний Google и Blue Shift опубликовали (https://medium.com/@duhroach/building-a-blazing-fast-et...) открытую реализацию упаковщика текстур на базе алгоритма сжатия ETC2 (Ericsson Texture Compression), обеспечивающего высокую эффективность сжатия при сохранении качества исходного изображения. Формат ETC2 включён в стандарт OpenGL ES 3 и не требует выплаты отчислений за использование запатентованных технологий. Код распространяется (https://github.com/google/etc2comp) под лицензией Apache 2.0.
Распространяется как инструментарий для сжатия текстур в командной строке, так и библиотека для применения в сторонних проектах. Основное внимание при разработке уделено скорости кодирования, что позволяет заметно сократить время компиляции игровых приложений, поставляемых с большим набором ресурсов, а также уменьшить размер итогового пакета. В том числе, инструментарий может помочь сократить размер приложений для устройств виртуальной реальности, которые требуют наличия значительно большего объёма высококачественных текстур.
Для того, чтобы ощутить насколько назрела необходимость появления быстрого упаковщика можно привести следующие сведения: наиболее популярный упаковщик Mali GPU Texture Compression tool (http://malideveloper.arm.com/resources/tools/) в среднем тратит около 640 секунд (10 минут) на одну текстуру. В типичной игре на базе движка Unity поставляется от 500 до 1500 текстур, т.е. на упаковку всех текстур уходит от 3 до 12 дней. В ситуации приложений для работы с виртуальной реальностью объём текстур и время на их упаковку увеличивается в 2-4 раза.
Новый упаковщик тратит на сжатие текстуры в среднем 10 секунд, т.е. работает в 64 раза быстрее упаковщика Mali. Подобного ускорения удалось добиться благодаря тонким настройкам режимов работы, многопоточной архитектуре и реализации упорядоченного поиска блоков с учётом их типов (ETC2 разбивает изображение на блоки 4x4, каждый блок может быть 10 типов, что для картинки 1024x1024 требует выбора оптимального варианта из 10⁶⁵⁵³⁶ комбинаций).
URL: https://medium.com/@duhroach/building-a-blazing-fast-et...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45173
Огласите пожалуйста список патентов?
> Формат ETC2 включён в стандарт OpenGL ES 3 и не требует выплаты отчислений за использование запатентованных технологийвроде как, в статье написано. Догадываюсь, что Khronos Group.
клоун: Не требует выплат, но это не означает отсутствия иных ограничений.
Да нет там никаких особых ограничений. MS таки додавится жабой вместе с эпплом. И рулить в результате будет вулкан, тогда как DX12 и Metal - ну вы поняли. Благо вулкан даже на андроиде работать будет.
Назови 5 игр класса ААА за последние 5 лет, которые вышли на Vulkan, но не вышли на DirectX, пожалуйста.
А теперь почитай когда Вулкан вышел!!!
> Назови 5 игр класса ААА за последние 5 лет, которые вышли на
> Vulkan, но не вышли на DirectX, пожалуйста.Первый выпуск vulkan: 16 февраля 2016 г.
Лишь бы пи**нуть...Можно ведь дурацкие аргументы и в обратную сторону поворачивать - была ли у DirectX портируемость на андроид в первые пол года после выхода первой версии?
Что, тогда не было андроида? Ну, вы первый начали требовать дебильные вещи :)
клоун: не слежу, не знал. Но даже полгода большой срок чтобы уже что-то вышло. И где?
З.Ы.
если бы было написано "клоун, ..." - тогда это типа обращение к оппоненту
но тк "клоун: ...", значит, клоун вещает. то есть ты сам себя клоуном открыто называешь.
ну неплохо
[offtopic]
> но тк "клоун: ..."Ты что первый день на OpenNET?
[/offtopic]
"какой-то профессиональный юмор"
DOOM 2016 И СКОРО НА ЕГО ДВИЖКЕ quake И Т.Д.
> DOOM 2016Но как же... Денуво...
:(
Дум. Хотя это довольно предсказуемо, если вспомнить политику id. И нет, полгода для разработки игры - это ничтожный срок.
> у DirectX портируемость на андроид в первые пол года после выхода
> первой версии?Ее у DX нету и спустя цать лет :). Как максимум можно приклеить на скотч прослойку, но прослойки дурят и на писюках то а на андроиде будет совсем вешалка. Там железо странное и слабое, с прослойками можно будет вволю посношаться и пожалуй написать оптимизированный рендерер на вулкане может оказаться проще.
> Назови 5 игр класса ААА за последние 5 лет, которые вышли на
> Vulkan, но не вышли на DirectX, пожалуйста.Я лучше скажу что вулкану едва полгода а рендереры под него сделали уже и поболее чем 5 AAA игр. Почти все новые игры идут с вулканом. При том они поюзают линь как testbed, а потом по мере появления вулкана в ведроиде - просто перенесут игры и туда.
Преимущество вулкана: он простой и работает везде более-менее одинаково. И к тому же быстрый. Поэтому они перенесут игры на ведроид без особых напрягов. Единственным отличием будет оптимизация под слабое железо. Поскольку далеко не все являются хардкорными геймерами и покупают последнее железо - это все-равно делать приходится, если продажи интересуют.
А за сколько можно сделать драйвер вулкана иллюстрирует RADV - опенсорсный вулкан для GCNов. Ему наверное месяц, его пилят 2 человека между делом. А он уже доту запускает. У которой есть рендерер на вулкане. Есть ли в доте рендерер DX12 - вот это я не знаю. Хотя-бы потому что у меня нет винды.
> DX12Судя по спецификациям это спи***ный Vulkan. Но судя по всему они это и не скрывают.
>Mali GPU Texture Compression tool в среднем тратит около 640 секунд (10 минут) на одну текстуру.Еще бы описали, что за процесс такой сложный и зачем он нужен в итоге.
ETC2 разбивает изображение на блоки 4x4, каждый блок может быть 10 типов, что для картинки 1024x1024 требует выбора оптимального варианта из 10⁶⁵⁵³⁶ комбинаций
Что-то подобное было в id Tech 5. Только называлось MegaTexture и появилось раньше этого.
> Что-то подобное было в id Tech 5. Только называлось MegaTexture и появилось
> раньше этого.Вообще разные технологии. ETC это непатентованный вариант вещей типа STC/DXTC/... - т.е. сжатия. А мегатекстуры в doom - просто блоки текстур. К сжатию мегатекстуры не относятся никак, просто более быстрый (по мнению автора движка) способ адресации.
> А мегатекстуры в doom - просто блоки текстур.Вообще-то там тоже используется сжатие. Учите матчасть.
https://en.wikipedia.org/wiki/Id_Tech_4#MegaTexture_renderin...
В русской версии есть картинка даже https://ru.wikipedia.org/wiki/%D0%9C%D0%...
[зануда]
Это было до Doom ещё в Rage =)
[/зануда]
вообще-то в QUAKE wars, до Rage
> Еще бы описали, что за процесс такой сложный и зачем он нужен в итоге.Для сжатия текстур. Сжатые текстуры занимают меньше VRAM чем несжатые. А если так получилось что текстуры не влезли в VRAM - догружать их из внешней памяти раз в 10 медленнее. Как тебе идея получить в сцене 6FPS вместо 60? С сжатием текстур - текстуры могут быть получше а просадки - пореже :)
> Как тебе идея получить в сцене 6FPS вместо 60?Кратковременная просадка. В зависимости от программиста и железа вы можете как не заметить её так и наблюдать слайдшоу в течении нескольких секунд. Заметьте, что почти во всех играх с отрытым миром - мир рисуется чанками, то есть блоками 100х100 например, а остальные блоки прогружаются по мере вашего продвижения по "миру". Вообще-то RAM довольно быстрая и так как VRAM ещё быстрее, то удалить один массив и записать другой для неё не составит труда, единственное, что может её остановить - слабый процессор.
> Кратковременная просадка.Это зависит от того насколько сильно не хватает видеопамяти. Можно и постоянный обвал FPS с 60 до 6 получить, если VRAM не хватает всегда.
> В зависимости от программиста и железа вы можете как не заметить её так
Нельзя не заметить просадку скорости железа в 10 раз.
> и наблюдать слайдшоу в течении нескольких секунд.
Даже клин на 1-2 кадрах в шутере выбесит игроков: 6FPS = 167 ms на кадр. Игрок целиться нормально не сможет.
Сжатие позволяет при прочих равных класть более качественные текстуры в ограниченный по объему VRAM. Т.е. при прочих равных можно позволить себе более красивую картинку с более качественными текстурами при тех же параметрах железа. Вот все и возятся с сжатием текстур. Хорошо же когда игрок видит каждую царапинку на доспехе. А не просто мутную желтую фигню "я типа блестящие доспехи, но VRAM не хватило".
> Заметьте, что почти во всех играх с отрытым миром - мир рисуется
> чанками, то есть блоками 100х100 например, а остальные блоки прогружаются по
> мере вашего продвижения по "миру".Тем не менее, если в какой-то момент VRAM не хватит для отображения сцены со всеми эффектами и текстурами - FPS грохнется вникуда. А если там VRAM нету, а-ля интеграт - бандвиза шин в таких системах всегда не хватает и прогружать по ним еще и в разы более жирные текстуры опять же будет неудачной идеей.
> Вообще-то RAM довольно быстрая и так как VRAM ещё быстрее,
Вообще-то RAM в разы медленнее VRAM. Пример: у меня в системе RAM 20Гб/сек, VRAM 180Гб/сек. Разница в 9 раз. Если это dGPU - там еще PCI-E. И даже 3.0 с 16 линиями не сравним с VRAM.
> то удалить один массив и записать другой для неё не составит труда,
В системах без VRAM CPU и GPU на пару дерутся за шину, ее вечно не хватает. Из-за этого интеграшки без VRAM и не могут конкурировать с dGPU по скорости. Когда CPU молотит он и сам шину нагружает. А тут GPU, которому одному то этой RAM мало (для понимания: DDR3 паяют только на совсем уж затычки для слота). АМД в Fury и подобных сделали аж 4096-битную шину. Она настолько широкая, что ее не смогли развести по плате. Пришлось чипы VRAM и GPU соединять на кремниевой подложке.
> единственное, что может её остановить - слабый процессор.
JFYI, процессоры быстрее оперативки практически везде. Даже в смартфонах уже.
клоун: чё-то какую-то фигню прогнали.По сути работает тот же принцип, что и в формате DjVu: изображение разбивается на небольшие блоки, каждый из которых сжимается своим алгоритмом. Есть перечень поддерживаемых алгоритмов и программы-архиваторы, напр. Mali.
В зависимости от целей, можно настроить Mali сжимать всё одним алгоритмом, выбирать наиболее сильное сжатие из всех алгоритмов или указать размер допустимой деградации качества (напр. JPEG с 65% качеством и JPEG с 90% качеством сильно различаются по размеру и качеству). Если выбрать наилучшее сжатие при макс. 10% потерь качества, то каждую текстуру придётся пересжать всем чем можно чтобы сравнить и выбрать лучшее. 10 минут для такой задачи - это вполне нормальное время.
Недавно в список стандартов попал новый формат сжатия - ETC2. В ближайшем релизе он будет включён (а может и уже включён) в состав Mali.
> ускорения удалось добиться благодаря тонким настройкам режимов работы
Вот в это верю. Программа с тюнингом обгонит ту же программу в стандартной поставке если сравнивать их в синтетическом тесте.
> работает в 64 раза быстрее упаковщика Mali
А вот в это не верю. Чтобы получить такую дикую разницу в производительности, разработчики Mali должны были неслабо накосячить.
В новости в одну кучу свалили новый алгоритм сжатия ETC2 и его реализацию. В сравнении тяжёлого с кислым победил Google.
> клоун: чё-то какую-то фигню прогнали.фигню здесь прогнал ты. ETC2 это стандарт, а Mali GPU Tool и эта программа — его реализации. И 10 минут на сжатие "достаточно всем" только сами знаете где.
А чего бы гуглю и не побеждать? Гугль нанял себе немало специалистов по сжатию данных и алгоритмам. Хорошее сжатие в GL ES? А они в андроиде этим пользуются. Это делает их систему лучше. На ней на тех же ресурсах можно запустить игры с более хорошим качеством картинки и при том не залетая на выплаты всяким вымогателям.У гугла есть и специалисты по сжатию в духе LZ для более обычных данных, с уклоном на вебстраницы. Они запилили формат сжатия Brotli который жмет почти как LZMA а скорость распаковки - как у zlib. Уже есть модули для нжинкса и апача, уже поддерживается хромом. Поэтому те кто пользуется опенсорсом и продуктами гугля - уже в плюсе: сайты грузятся быстрее при прочих равных. Меньше данных качается. Иногда - в разы.
У гугля есть спецы по сжатию видео. AV1/AOM - это 70% гугловский VP10, 20% daala и остальное по мелочи - вкрапления технологий из цисковского thor и что там еще. Реально коммитит в основном гугл. Иногда мозилла. В порядке исключения есть пара чуваков из цыски. Ну а ms крутая и технологичная компания - оказывает моральную поддержку. Тем что хотя-бы не мешает :).
клоун: Какое отношение всё это имеет к обсуждаемой теме?Есть:
1. алгоритмы сжатия, стандартизированные в OpenGL, один из которых ETC2
2. программа-архиватор Mali, реализующая ETC2 и ещё десяток других алгоритмов
3. безымянная программа-архиватор от Google, реализующая только ETC2Что с чем сравнивалось и с какими настройками что была получена 64-кратная (!) разница?
Что изображено на графике? Я вижу два алгоритма со сложностями O(1) и O(N^2). Такое бывает когда оптимизированную сортировку сравнивают с поплавком, но когда коммерческий продукт, который держит 90% этого рынка сравнивают с программой, у которой даже нет имени...
> клоун: Какое отношение всё это имеет к обсуждаемой теме?Самое непосредственное: гугл и тут нанял пару толковых парней под свои задачи.
> 2. программа-архиватор Mali, реализующая ETC2 и ещё десяток других алгоритмов
Да это ее проблемы. Если кому не западло ждать в 64 или сколько там раз дольше - они в своем праве.
> Что изображено на графике? Я вижу два алгоритма со сложностями O(1) и
> O(N^2). Такое бывает когда оптимизированную сортировку сравнивают с поплавком,Ну так если гугл может написать "оптимизированную сортировку" в своей области - это хорошо и правильно. А такие как ты могут вопить о том что ваш поплавок это круто до упупения. На винде все алгоритмы как-то так и работают в результате: оптимизации у виндовозов не в почете. Вот прям начиная с операционки, про состояние дел в которой недвусмысленно писал виндовый же разработчик. Разработчика потом стерли, но джинн из бутылки вылез и обратно уже не того :).
> JPEG с 65% качеством и JPEG с 90% качеством сильно различаются по размеру и качествупо размеру, но не по качеству :)
клоун: от картинки зависит. Возьми белую картинку с чёрными полосами: белая полоса в 1 пкс, чёрная полоса в 1 пкс. Пережми её в PNG, JPG 65, JPG 90 и зацени разницу.
Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в разы.
> Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в
> разы.Заметишь, при 65% jpeg - мыло, только что проверил в GIMP. Причём некоторые полоски слились. Не думал, что это скажу когда-нибудь, но Клоун тут прав.
> Дно, в большинстве случаев - не заметишь разницы, а размер уменьшается в разы.Жпег - для изображений типа фотографий, с градиентами. PNG - для line art и прочей computer-generated графики типа скриншотов с большими однородными площадями.
Как ни странно даже такой деград как клоун про это в курсе. Те кто этого не знал - должны просто устыдиться своего ламерства. Быть глупее клоуна... ух, это даже круче чем быть посланным на...й!
> Быть глупее клоуна.Он не глупый, он просто тролль.
Теперь в Mesa смогут запилить поддержку перекодирования на лету из кучи форматов в один прекрасный ETC2?
И станет всё быстрее и не нужно будет покупать видеокарты с большим объёмом видеопамяти?
