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

Как узнать сколько может влезть в glBufferData? (2 стр)

Страницы: 1 2 3 Следующая »
#15
12:25, 15 апр. 2019

FlyOfFly
А как еще писать Load Balancer для всех GPU.


#16
12:39, 15 апр. 2019

lookid
> Тоесть когда у тебя зоопарк GPU, то ты тупа бинарным поиском бегаешь по size_t
> и ловишь OUT_OF_MEMORY для определения лимита памяти? Хм.

какие иные варианты?

#17
12:48, 15 апр. 2019

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGet.xhtml
GL_MAX_ELEMENTS_VERTICES
Если такого нет, то только вендор-специфик

#18
13:16, 15 апр. 2019

http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt
https://www.khronos.org/registry/OpenGL/extensions/ATI/ATI_meminfo.txt
Для NV есть еще сишные либы:
https://developer.nvidia.com/nvidia-management-library-nvml

#19
13:41, 15 апр. 2019

Опять срачь)
Ну в общем : выяснили что ничего не выяснили.
lookid
> GL_MAX_ELEMENTS_VERTICES
Там же написано что он к  glDrawRangeElements относится.

#20
22:21, 15 апр. 2019

vindast
> Опять срачь)

а як жешь

Fantom09

и что либы дают?

#21
(Правка: 3:47) 3:45, 16 апр. 2019

innuendo
> и что либы дают?
Количество свободной видеопамяти, это не ответ на вопрос о размере буфера, но позволит ориентироваться в доступной приложению памяти. Это если речь идет об утилизации всех ресурсов видеокарты. Аналогичные утилиты есть и у других вендоров, у АМД это вроде ADL (AMD Display Library), у интела вроде gmmlib(Graphics Memory Management Library) с аналогичными функциями.

Но я бы предложил юзать вендорные расширения OpenGL для этого, прописать пару условий на вендора проще чем таскать за собой кучу либ под каждого вендора.
Примеры здесь: https://www.geeks3d.com/20100531/programming-tips-how-to-know-the… ge-in-opengl/

Ну и ответ на вопрос топикстартера - если нужен "теоретический максимальный" размер буфера VBO, то его можно получить через размер SSBO, что в принципе одно и тоже:
glGetIntegerv(GL_MAX_SHADER_STORAGE_BLOCK_SIZE, &size);

Вот только эта величина - константа, тоесть не важно сколько у тебя реально свободной памяти, оно будет возвращать постоянно одно и тоже значение, что делает эту константу бесполезной (в отличии от размера UBO, где можно легко упереться в максимум).

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

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

#22
7:50, 16 апр. 2019

vindast
> glGetIntegerv(GL_MAX_BUFFER_SIZE, &x);
какая тебе разница, какой максимальный размер буфера поддерживает GAPI, если железо тебе буфер такого размера всё равно не отдаст?

#23
10:28, 16 апр. 2019

Suslik
> какая тебе разница, какой максимальный размер буфера поддерживает GAPI, если
> железо тебе буфер такого размера всё равно не отдаст?

а GAPI не смотрит на капсы железа ?

#24
(Правка: 10:50) 10:48, 16 апр. 2019

innuendo
не в капсах железа дело, а в текущем состоянии памяти. представь, это как иметь размер максимальной памяти, который можно выделить на куче — на x64 машине это будет теоретически 2^64, только какая разница, если у пользователя одним куском оперативы будет максимум на несколько гигов? капсы железа имеют смысл, когда речь идёт о принципиальном ограничении, которое железо может обрабатывать — например, железо не может обрабатывать больше 16 семплеров не потому что у него 16 семплеров в память не влезут, а потому что в железе всего 16 текстурных блоков.

#25
11:08, 16 апр. 2019

смешно видеть такие темы как
"Как узнать сколько может влезть в glBufferData?"

в век обилия готовых фреймворков и движков для устройств от кофеварок до теслы

#26
11:15, 16 апр. 2019

Suslik
> не в капсах железа дело, а в текущем состоянии памяти.

текущее состояние памяти это не железо -это всё вместе

#27
13:03, 16 апр. 2019

innuendo
Тут Суслик намекает, что если у человека возникает такой вопрос, то ему рано балансить пропускную способность и память видеокарт.

#28
13:22, 16 апр. 2019

Fantom09
> у АМД это вроде ADL (AMD Display Library),
В ADL этого нет, там даже объем локальной видео памяти не узнать, приходилось колхозить через WGL_AMD_gpu_association и то там показывается только набортная память, а не сколько используется.

#29
13:55, 16 апр. 2019

barnes
> В ADL этого нет
Возможно, я только с NV работал, глянул что в API ADL есть структуры ADLMemoryDisplayFeatures и ADLMemoryInfo, предположил что это аналог возвращаемой nvmlDeviceGetMemoryInfo структуры nvmlMemory_t. Вообще у АМД дофига SDK, что-то наверняка должно возвращать эту инфу :)
Из доки по ADL:

Prior to AMD Display Library (ADL), AMD provided several SDKs (PDL, DSP, CCC, COM) for external use under Windows, but none for Linux. The goal of ADL is to provide a single SDK for both operating systems and to eventually replace the other SDKs.
Страницы: 1 2 3 Следующая »
ПрограммированиеФорумГрафика