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

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

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

Страницы: 1208 209 210 211218 Следующая »
#3120
(Правка: 0:20) 0:16, 7 апр. 2019

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

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


#3121
0:26, 7 апр. 2019

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

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

#3122
1:57, 7 апр. 2019

Wolfraider
товарищ Morphia ?

#3123
3:21, 7 апр. 2019

/A\
> Еще теоретически драйвер может выгружать данные из видеопамяти в оперативную,
> если считает, что памяти может не хватить.
По-моему современные дрова это уже не умеют (кроме интела). У меня всегда при приближении к физическому объему видеопамяти начинаются ошибки, GL_OUT_OF_MEMORY и вскоре краш. Поэтому я слежу за ее потреблением, и был очень огорчён, когда года 3 назад AMD похерила свое расширение ATI_MEM_INFO (не помню точно название).

#3124
(Правка: 9:38) 9:36, 7 апр. 2019

Neptune
> о самое интересное то, что эта выделенная память не возвращается!
было нечто подобное - типа драйвер думает, что потом эта память повторно будет использоваться и ждёт

glFlush ?

>При этом встроенный профайлер вижуал студии ничего подозрительного не показывает

ну так - это же память драйвера

#3125
12:15, 7 апр. 2019

Не совсем, он ведь отжирает память у моего процесса, а она не резиновая (всего 4 гига).

#3126
(Правка: 12:29) 12:28, 7 апр. 2019

Neptune
> он ведь отжирает память у моего процесса

может он просто делает reserve?

#3127
15:43, 7 апр. 2019

Ну мне-то от этого не легче. Он ее не освобождает, пока glDeleteTextures не вызову. На 64 бита переходить - это, неверное, не один месяц... У меня много арифметики указателей.

#3128
(Правка: 17:10) 17:06, 7 апр. 2019

Neptune
> Он ее не освобождает, пока glDeleteTextures не вызову.

а ... так это другой кейс

тогда смотри в сторону sparse

#3129
12:14, 9 апр. 2019

Neptune
> Ландшафт 2.0
Все забываю спросить - есть ли у тебя в проекте Солнечная система и ландшафты планет Солнечной системы с правильными лунами/планетами на небе?

#3130
13:28, 10 апр. 2019

Конечно есть.
scr00815 | Космический симулятор SpaceEngine
scr00789 | Космический симулятор SpaceEngine
scr00816 | Космический симулятор SpaceEngine

#3131
4:54, 11 апр. 2019

Neptune
> > Еще теоретически драйвер может выгружать данные из видеопамяти в оперативную,
> > если считает, что памяти может не хватить.
> По-моему современные дрова это уже не умеют (кроме интела).

ты про линукс?

#3132
15:46, 11 апр. 2019

Нет, про винду.

#3133
22:13, 11 апр. 2019

Neptune
> Нет, про винду.

странно, на nvidia точно  можно было создавать текстуры больше чем VRAM

#3134
11:23, 18 апр. 2019

Драйвер нвидии теперь еще и при создании vbo наглым образом жрёт память и не освобождает. Никто не заметил? Может быть, это у меня в системе проблема?

Хотите верьте, хотите нет, но портирование SE на x64 заняло один вечер. Я сам в шоке! Всего лишь надо было собрать сторонние библиотеки под x64, и пару правок в коде сделать.

Вроде всё работает, какие-то подлагивания появились, SE отжирает 8 гигабайт и на этом успокаивается. При создании тех же самых текстурных массивов съедается сразу 4 гигабайта и так и не возвращается. Это всё-таки как-то неправильно, раньше такого не было.

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