Портирование проекта на OpenGL3 - PullRequest
7 голосов
/ 03 июня 2010

Я работаю над C ++ кроссплатформенным приложением OpenGL (Windows, Linux и MacOS), и мне интересно, могли бы некоторые из вас поделиться некоторыми советами по переносу большого приложения на OpenGL 3. Почему я смотрю на OpenGL 3, потому что я думаю, что мы могли бы извлечь большую пользу из использования новых «объектов синхронизации». Nvidia поддерживает такое расширение с Geforce 256 дней (gl_nv_fences), но, похоже, не было эквивалентной функциональности на оборудовании ATI до OpenGL 3.0 + ...

Наш код довольно интенсивно использует функции glut / freeglut, glu, расширения OpenGL 2 и CUDA (на поддерживаемом оборудовании). Проблема, с которой я сейчас сталкиваюсь, заключается в том, что «gl3.h» и «gl.h» несовместимы друг с другом (как указано в gl3.h). Ребята, вы знаете, есть ли эквивалент GL3? Также, глядя на заголовочные файлы набора инструментов CUDA, кажется, что совместимость GL-CUDA доступна только при использовании более старых версий OpenGL ... (cuda_gl_interop.h включает gl.h ...). Я что-то упустил?

Большое спасибо за вашу помощь.

1 Ответ

3 голосов
/ 03 июня 2010

Последнее обновление для перенасыщения было версия 3.7, примерно 10 лет назад. Учитывая это, я сомневаюсь, что он будет когда-либо поддерживать OpenGL 3.x (или 4.x).

Люди, работающие над OpenGlut , похоже, рассматривают возможность поддержки OpenGL 3.x, но пока ничего с этим не сделали.

FLTK имеет (частичное) моделирование перенасыщения, но оно достаточно частичное, чтобы программа, которая "интенсивно использует перенасыщение", могла не работать с ним. Поскольку FLTK находится в активной разработке, я предполагаю, что в конечном итоге он будет поддерживать OpenGL 3.x (или 4.x), но я не верю, что он уже предоставлен, и может возникнуть вопрос, как скоро он будет .

Редактировать: Что касается CUDA, очевидный (хотя, конечно, нетривиальный) ответ будет вместо этого использовать OpenCL. Это значительно лучше совместимо как с аппаратным обеспечением (например, с платами ATI / AMD), так и с более новыми версиями OpenGL.

Это оставляет глу. Честно говоря, я не думаю, что есть четкий или очевидный ответ на это. OpenGL отодвигается от от поддержки таких вещей, как glu, и вместо этого отказывается от поддержки еще большей части неопределенно подобной glu-функциональности, которая раньше была частью базовой спецификации OpenGL (например, всех примитивов манипулирования матрицей). Лично я считаю, что это ошибка, но хорошо это или плохо, но так оно и есть. К сожалению, glu немного похож на перенасыщение - последнее обновление спецификации было в 1998 году и соответствует OpenGL 1.2. Это не делает обновление кажется вероятным. К сожалению, я не знаю ни одной действительно прямой замены для этого. Очевидно, есть другие графические библиотеки, которые предоставляют (по крайней мере некоторые) аналогичные возможности, но все они, о которых я могу подумать, потребуют существенного переписывания.

...