| |
| 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.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.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 - просто блоки текстур. К сжатию мегатекстуры не относятся никак, просто более быстрый (по мнению автора движка) способ адресации.
| | |
|
|
| 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 графики типа скриншотов с большими однородными площадями.
Как ни странно даже такой деград как клоун про это в курсе. Те кто этого не знал - должны просто устыдиться своего ламерства. Быть глупее клоуна... ух, это даже круче чем быть посланным на...й!
| | |
|
|
|
| 1.38, Аноним (-), 19:33, 23/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Теперь в Mesa смогут запилить поддержку перекодирования на лету из кучи форматов в один прекрасный ETC2?
И станет всё быстрее и не нужно будет покупать видеокарты с большим объёмом видеопамяти?
| | |
|
