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

glGetIntegerv - краш при любом раскладе

#0
9:42, 16 мая 2017

Странное дело, при любом раскладе glGetIntegerv валит софт...
так падает

GLint test;
glGetIntegerv(GL_TEXTURE_BINDING_2D, &test);
и так тоже
GLint ExtensionCount;
glGetIntegerv(GL_NUM_EXTENSIONS, &ExtensionCount);
std::cout << ExtensionCount;

собственно исключение классическое:

Unhandled exception at 0x0000000000000000 in mirage.exe: 0xC0000005: Access violation executing location 0x0000000000000000.

В чём фокус - то? Драйвер GL левый?

так...походу версия glGetIntegerv 32-х битная, а софт - x64. Ну вот пробую glGetInteger64v и тому подобные - те же яйца, только в профиль ))) Бред какой то...

P.S.: наверное зря я решил перегнать рендер с чистого OpenCL на OpenGL, с дровами GL на разных машинках траблов будет немерено...


#1
9:54, 16 мая 2017

Глаза-то разуй, а?
Тебе ясным английским языком сказано:
>executing location 0x0000000000000000
то есть твоя glGetIntegerv - неинициализированная процедурная переменная. Ты вызываешь NULL.

#2
10:03, 16 мая 2017

Cheb
> то есть твоя glGetIntegerv - неинициализированная процедурная переменная.
это что ещё за, пардон, говно динозавра ))) Ты хочешь сказать, что в pure GL нужно как - то явно связывать функции и конкретные библиотеки GL и что у меня GL не инициализировать или чего?

эта штука вообще из gl3w:

#define glGetIntegerv                                 gl3wGetIntegerv
я что то забыл подгрузить или что? :-)

#3
10:07, 16 мая 2017

Для этого есть либы вроде GLEW. В них нуча функций на самом деле просто являются указателями и равны NULL, пока не будут инициализированы (при валидном контексте).
Т.е. скорее всего не инициализирована соответтвующая либа, либо нет валидного контекста OpenGL

#4
10:10, 16 мая 2017

steps3d
> Т.е. скорее всего не инициализирована соответтвующая либа, либо нет валидного
> контекста OpenGL
да, спс, я так и подумал... В оригинальном проекте я конечно никогда не буду использовать подобное кхе кхе чудо кодерства в стиле 'С' 80-х годов. Хотя вроде всё инициализировано, ладно, пойду ещё покопаюсь :-)

#5
10:12, 16 мая 2017

-=MASTER=-
> В оригинальном проекте я конечно никогда не буду использовать подобное кхе кхе
> чудо кодерства в стиле 'С' 80-х годов.

Да не вопрос, есть OpenInventor/osg

#6
10:19, 16 мая 2017

innuendo
> Да не вопрос, есть OpenInventor/osg
на самом деле есть Qt, в котором тот же OpenGL очень удачно обёрнут, что можно не парится из - за вот таких вот мелочей. А так же есть OpenCL, на котором можно реализовать весь рендер и результирующую картинку загонять напрямую в текстуру OpenGL/DirectX.
Я собственно почему задумал протестировать всё на OpenGL, вместо OpenCL... Вроде как в OpenGL/DirectX и пр растеризатор работает хардверно, причём без участия непосредственных SM процессоров GPU, то есть вроде как на видео картах есть специальный сопроцессор для растеризатора, доступ к которому нельзя получить из OpenCL. Я вот просто не знаю, геново это или нет? Или этот растеризатор на уровне драйвера тупо использует те же потоковые ядра GPU (SM/SMX и пр), как и обычный шейдер и нет никого специального "железного" со-процессора спецом для растеризатора?

#7
10:23, 16 мая 2017

Я тоже гдето слышал что растеризатор имеет больше вычислительных юнитов,  и параллеллизм больше при рендере текстуры чем пересчет rwbuffer в cuda.

#8
10:30, 16 мая 2017

Mira
> Я тоже гдето слышал что растеризатор имеет больше вычислительных юнитов,  и
> параллеллизм больше при рендере текстуры чем пересчет rwbuffer в cuda.
да я вот тоже где - то читал, просто хотелось бы пруф увидеть, а то ща потрачу кучу времени на перегонку на OpenGL и растеризатор, а в итоге FPS упадёт...

#9
10:49, 16 мая 2017

-=MASTER=-
> . Я вот просто не знаю, геново это или нет?

Нет. В крайнем случае, многое можно вынести на cs. Но сам рендер на GL. Если только не ray-trace :)

#10
10:51, 16 мая 2017

innuendo
> Если только не ray-trace :)
cone trace :-)

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

Тема в архиве.