Войти
ПрограммированиеФорумГрафика

Затык с упаковкой данных. (Opengl / glsl) (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#15
2:51, 6 ноя. 2018

MrShoor
> опозорился
Стараюсь.


#16
(Правка: 4:05) 3:49, 6 ноя. 2018

vindast
Крузис делает, как я тебе скинул линк. Переводим RGB->YCC. Далее идет шахматная упаковка. В R-канал текстуры сохраняешь яркость (Y), в G - хранится Cb, если пиксель четный и Cr если не четный. Я уверен есть способы вообще, еще больше зажать. Но восстановление будет наверняка долгим, из-за множества обращений к соседним пикселям

#17
(Правка: 5:36) 5:33, 6 ноя. 2018

MrShoor прав - ты получил то что заказывал - 4 бита на хрома, что и выражается в потере цветовой информации.

Если ты пытаешься повторить YCbCr 4:2:2 схему, то ты ее неправильно понял - смысл не в том чтобы убить биты (как ты вообще себе представляешь восстановление потерянной информации потом?), а в том чтобы не тратить фулл-рез на низкочастотную инфу.

В отличие от яркости (Y), хроматическая составляющая низкочастотная, а значит мы можем понизить частоту дискретизации (проще говоря - разрешение), без особой потери в качестве.  Т.е. ты Y хранишь в фулл-рез, а Cb и Cr -> в халф рез. Например чрезстрочно, или шахматкой. А в осободившиеся дырки пихай другую инфу не требующую фулл реза.

Тогда для восстановления ты апсамплишь хроматику и получаешь исходную картинку.

Правка:  IBets  по сути то же самое ответил, сорян, не заметил.

Правка 2:
IBets
> восстановление будет наверняка долгим, из-за множества обращений к соседним пикселям
В теории они все равно будут в кеше, и "спрячется" долгими ALU. Профайлить надо. Если затык в BW - то в принципе это вариант.

#18
13:17, 6 ноя. 2018

Окей. Вас понял.
Можно при таком подходе не парится с битовой упаковкой даже.
Попробую сделать так.
0r@ngE
> YCbCr 4:2:2
8:4:4

#19
14:26, 6 ноя. 2018
puck\unpuck это в пёрлы однозначно :-)
#20
16:05, 6 ноя. 2018

Сделал чередование (через пиксель, горизонтально), YCoCg. Цвет линейный, без тонмапа и гаммы.

Слева без преобразований (текстура дифуза), слева с чередованием YCoCg.

Изображение
Изображение

Сама кодировка не очень, YCbCr лучше?

Теперь понял зачем IBets использует edge-detection. И вот начал сомневаться, может лучше не стоит паковать дифуз? Как-то много чтений с текстуры получается. Четыре штуки на семпл.
Хотя если посчитать что в текстуры может быть (Y, Co/Cg, roughness, metallic) то один раз можно читать все четыре компонента, и три раза только xy-компонент (а может даже и только Y). Это должно же помочь?

Посмотрел код IBets и он использует область 2*2 для кодирования. Он еще чередует нормали с roughness / metallic. Я вот думаю, что картинка будет заблюрена в усмерть. Даже сейчас с моим 1 * 2 (только цвет) видно что цвет блюрится. А если паковать нормали, и сделать тот-же sslr (фул - рез) c четкими отражениями, то может получится полная хрень.

В общем. Стоит ли овчинка выделки, или лучше забить?

#21
18:42, 6 ноя. 2018

vindast
> или лучше забить?
Судя по скриншотам - вы где-то вначале пути написания движка. Я бы порекомендовал отложить оптимизации на потом, и лучше потратьи время с пользой расширяя функционал.
Оптимизации не делаются "а шоб було", для этого нужно понимать свои bottlenecks.

#22
(Правка: 19:19) 19:13, 6 ноя. 2018

0r@ngE, ну почти)

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

+ Показать

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

Хочется что бы моя личинка движка наконец переросла в что-то большее)

#23
19:57, 6 ноя. 2018

Для начала стоит сделать техно демку, в которой будут использованы все фичи движка, которая будет "симулировать" реальную нагрузку.
Это поможет понять где затыки и куда копать (а может ввобще все в CPU упрется).

> Хочется что бы моя личинка движка наконец переросла в что-то большее)
Этим и рекомендую заняться, нет смысла зарываться в оптимизации на данном этапе.

#24
20:05, 6 ноя. 2018

vindast
Да лучше оставь на потом,  как ты сделал объемный свет?

#25
(Правка: 20:31) 20:22, 6 ноя. 2018

0r@ngE
> Для начала стоит сделать техно демку, в которой будут использованы все фичи
> движка, которая будет "симулировать" реальную нагрузку.
> Это поможет понять где затыки и куда копать (а может ввобще все в CPU упрется).
Вот у меня в данный момент нет проблем с многопотоком, по тому что я распаралелил все что может быть распаралелено (пока кроме физики). Я только не знаю как сделать систему событий. Вариант с делегатами в многопоток не сможет, по тому что можно уперется в дедлоки. Думаю сделать что-то вроде наблюдателя со списками сообщений. У меня сейчас многопоток сделан как атомарные итераторы (возвращают небольшой диапазон) по выровненным по пемяти буферам. Батчинг вот сделаю (хочу изобрести свой велосипед).

0r@ngE
> Для начала стоит сделать техно демку, в которой будут использованы все фичи
> движка, которая будет "симулировать" реальную нагрузку.
> Это поможет понять где затыки и куда копать (а может ввобще все в CPU упрется).
Вот хочется ворваться выбив дверь с ноги, а не слушать что вон там косяк, и что еще вон там косяк) Меня лично ни сложность, ни количество нужного для этого времени не остановят.


0r@ngE
> смысла зарываться в оптимизации на данном этапе.
Очень хочется. Сделать все и сразу, если бы не хотел, мог бы просто собрать допилить старую версию:

IBets
> как ты сделал объемный свет?
Если коротко, восстановление геометрии объема света из его тени. Спорну что нвидус делает именно так.
Тык http://www.cyberforum.ru/opengl/thread2203290.html
Для каскадов так выглядит. Там он не доделан.

+ Показать

Более простой способ с рендором слоев распространения света (как унити) знаю.

#26
20:42, 6 ноя. 2018

>В общем. Стоит ли овчинка выделки, или лучше забить?
ответ

>Оптимизации не делаются "а шоб було", для этого нужно понимать свои bottlenecks.

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

#27
(Правка: 20:57) 20:51, 6 ноя. 2018

Danilw, ну в крайтеке умные же дяди сидят. Они же для чего-то это делали. Вот на пример в юнити ( на сколько я знаю) нет упаковок таких.

Да и сейчас точно вижу что можно пожать весь буфер до 96 бит.

Буфер глубины 32
rgba (y, co / cg, roughness, metalic + zSign)
rg16f s_norm (normalX, normalY)

#28
20:56, 6 ноя. 2018

Danilw
> В теории они все равно будут в кеше

#29
20:59, 6 ноя. 2018

Короче, сделаю. Все)

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумГрафика