Космический симулятор SpaceEngine (208 стр)

Neptune
твои непонятные запросы :)
вот если  делаешь , образно говоря , самописный рендер
то наверняка большая студия сделала уже лучше !

Neptune
может стоило бы перенести технологию на какой-нибудь Юнити
причем явно все успешные сжатия делаются в оперативе
именуется как дамп-памяти и не важно какой имеет образ

Neptune
можно лепить хоть по образу алкоголя или парагона сродни виртуальному диску
который хранит образ сжатых или других данных - нужно понимать что экранный кадр
вмещает в себя как в экран по разрешению этого экрана , и тут должны совпадать
параметры драйвера на заказываемый формат экрана и видео-карточка скорее вторична
желательно точно знать что хочешь - тогда возможны определенные решения

Хоаспаде, Wolfraider, не флуди здесь пожалуйста. Тебя всё равно никто не воспринимает всерьёз.

Neptune
извини , но за 10 лет твой продукт никуда не вышел не у меня , а у тебя
потомучто ты не знаешь даже архитектуры компьютера , но полез
очень далеко - даже если твой движек внедрить скомпоновав его с игровым
то не хватит никакой памяти не то что оперативной - причем ты сам это выразил - четко

Neptune
тебе бы следовало знать что слова фпс и экран означают почти одно и тоже или одно и тоже
количество данных первышающих необходимый выход на экран уже идет как овер-хеад

Neptune
можно сравнить туже проблему с космическими инженерами
их объекты из 30 тысяч элементов нагружают память и более одного объекта иметь уже нельзя
в принципе у тебя все тоже , да и движок пригодиться скорее всего никому ибо с ним
никто не управиться или некто один

Neptune
а максимальное количество слоев проверяешь? может только 1024 доступно

Проверяю, 2048, на всех мыслимых видеокартах, даже на древних интелах (делал опрос на форуме SE).

Neptune
> даже на древних интелах (делал опрос на форуме SE).

главное - капс проверить

Neptune
> Дело в том, что напрямую рендерить в сжатую текстуру нельзя - ее нельзя
> приаттачить каки рендер-таргет к fbo. Поэтому сжатие текстур шейдером делают,
> сначала рисуя им во вспомогательную int текстуру, а потом побитово копируя ее в
> сжатую через pbo. Так вот, это копирование

не понял - а как ты сжимаешь? при записи в fbo ?

Neptune
можно еще попробовать sparse texture, если на амд по какой-то причине не получается выделить сплошной кусок памяти

innuendo
> не понял - а как ты сжимаешь? при записи в fbo ?
Делал по статье нвидиа https://www.nvidia.com/object/real-time-ycocg-dxt-compression.html
Статья довольно старая, но всё, что видел из нового, это вариации того же метода:
- сначала рендер в int32 рендер таргет разрешением 1/4 исходной текстуры,
- затем копирование его в мип-уровень сжатой текстуры через glCopyImageSubData.

/A\
> можно еще попробовать sparse texture, если на амд по какой-то причине не
> получается выделить сплошной кусок памяти
Так оно же просто крашится, без всяких сообщений об ошибках. Старым методом, через glTexImage3D/glCompressedTexImage3D с загрузкой массива нулевых байт - работает.

При размере 1536 слоев - создаются первые два массива, на третьем снова краш.
Может быть, надо включить или отключить какой-то стейт перед этим? Помнится, несколько лет назад были краши на glGenerateMipmap, если перед этим не сделать glEnable(GL_TEXTURE_2D). Драйвера AMD такие качественные...

Neptune
> - сначала рендер в int32 рендер таргет разрешением 1/4 исходной текстуры,
> - затем копирование его в мип-уровень сжатой текстуры через glCopyImageSubData.

сделать через compute shader ?

innuendo
> сделать через compute shader ?
Не встречал примеров нигде.

innuendo
> сделать через compute shader ?
На огл вроде бы нельзя сделать вию с несжатым форматом для сжатого формата.

В вулкане есть такая фича

Neptune
представь спрайт Луны целиком - реальный или нагенеренный - все равно
дальше его размер в Террабайтах или даже неважно в чем

Neptune
нужны быстрые чек-поинты по которым прибывает тельняшка на командный пункт
то есть то что натягивается на объект подается порционно - таким образом
требуется стэк по размерам для проглатывания в итоге одного кадра (+ иная технология)
здесь вернее фрейма который и есть фпс по кадрово в количестве кадров на размерность "С"

Neptune
если бы некто кто шарит в ЛИСПЕ , который служит для рассчетов
смастерил тебе dll которую добавить в загрузочную систему ,
то далее им можно пользоваться и как открытым юнитом по подключению

так и через оперативу , если вдруг хэндлы открываются даже через АПИ видвоза то
даже прокатит как доп.альтернатива , возможно некто вроде Suslik мог бы проконсультировать
и даже Slava_MIB что-то да точно знает про мин-уровни , где-то это кажись проскальзывало
они же Life is Feudal разработали

С glTexStorage3D на нвидии какие-то веселые эффекты начались. Первый же вызов glFramebufferTextureLayer для аттача слоя текстурного массива к fbo, зачем-то выделяет в основной памяти кусок, примерно равный по объёму всему мип-уровню массива (а у массива 256*256 на 2048 слоёв это сотни мегабайт, он ведь считается сразу для всех слоёв). Это нормальное поведение? Зачем она вообще это делает, как будто маппит текстуру в оперативу?

Но самое интересное то, что эта выделенная память не возвращается! Т.к. движок создаёт с десяток массивов по 100-600 Мб, он быстро достигает 4 гигабайт и крашится (т.к. 32-битный). При этом встроенный профайлер вижуал студии ничего подозрительного не показывает, только какие-то килобайты, выделенные в недрах glFramebufferTextureLayer.

glTexImage3D/glCompressedTexImage3D, кстати, тоже выделяют себе память, как будто копируют переданный массив байт ещё куда-то. Может быть, это не выделение памяти, маппинг куска ВИДЕОпамяти в адресное пространство процесса через PCI-E шину? Ну допустим, с glTexImage3D тогда понятно, и в ней утечек нет. Но зачем glFramebufferTextureLayer этим занимается, она же не связана с пересылкой данных с/на ЦПУ?

На радеоне glTexStorage3D падает, потому что зачем-то начинает выделять туеву хучу гигабайт памяти. Нвидия таким не страдает. Отслеживаю Process Explorer-ом.

Edit: вот оно, вот оно! https://community.amd.com/thread/218345
Багрепорт 2017 года, проблема всё ещё есть... Дрова сегодня обновлял.