Войти
ПроектыФорумУтилиты

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

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

Страницы: 1207 208 209 210212 Следующая »
#3105
(Правка: 23:27) 23:12, 5 апр. 2019

>Через glCopyImageSubData ?
да

Через glTexStorage прокатило на нвидии, на ати крашится, std::bad_alloc() где-то в недрах glTexStorage3D(). Причем даже на несжатых.

Псевдокод:

    // массив 16-битных grayscale текстур
    width = 256;
    height = 256;
    layers = 2048;
    nMips = 9;

    glGenTextures(1, &id);
    glBindMultiTexture(GL_TEXTURE0, GL_TEXTURE_2D_ARRAY, id);

    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_BASE_LEVEL, 0);
    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAX_LEVEL,  nMips-1);

    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);

    glTexStorage3D(GL_TEXTURE_2D_ARRAY, nMips, GL_R16, width, height, layers);


#3106
23:26, 5 апр. 2019

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

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

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

#3107
23:29, 5 апр. 2019

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

#3108
23:42, 5 апр. 2019

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

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

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

#3109
0:16, 6 апр. 2019

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

#3110
3:46, 6 апр. 2019

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

#3111
(Правка: 8:08) 8:05, 6 апр. 2019

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

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

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

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

#3112
8:17, 6 апр. 2019

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

#3113
(Правка: 12:41) 12:40, 6 апр. 2019

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

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

#3114
(Правка: 20:57) 13:15, 6 апр. 2019

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

#3115
(Правка: 13:50) 13:33, 6 апр. 2019

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

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

#3116
19:23, 6 апр. 2019

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

#3117
(Правка: 20:37) 20:26, 6 апр. 2019

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

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

VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT specifies that the image having a compressed format can be used to create a VkImageView with an uncompressed format where each texel in the image view corresponds to a compressed texel block of the image.

#3118
21:03, 6 апр. 2019

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

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

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

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

#3119
23:59, 6 апр. 2019

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

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

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

Страницы: 1207 208 209 210212 Следующая »
ПроектыФорумУтилиты