Каковы отношения между EGL и OpenGL?

Я пишу реализацию OpenVG и OpenGL / ES на Go, оба из которых зависят от Khronos EGL API, якобы для облегчения переносимости думаю.

Я пишу реализацию OpenVG поверх OpenGL ES по забавным и образовательным причинам - я не сделал много работы по рендерингу, и я хотел бы узнать больше об открытых API и практике реализации четко определенных стандартов (легче увидеть, если я получил правильный результат.)

Как я понимаю, EGL предоставляет стандартный API для извлечения контекста рисования (или того, что он правильно называется) вместо использования одного из нескольких API, предоставляемых ОС (GLX, WGL и т. д.)

enter image description here

Мне трудно поверить, что Хронос пройдет через такие усилия и оставит стандартный OpenGL вне цикла, но дело в том, что я не нашел, как Или если OpenGL (реальная сделка) взаимодействует с EGL или если это только OpenGL ES. Если OpenGL ES может использовать контекст рисования из EGL, будет ли стандартный OpenGL также работать?

Я действительно Новичок во всем этом, поэтому я взволнован, но реальный проект, который я делаю, - это набор инструментов GO widget, который использует OpenVG для своих операций рисования и использует аппаратное ускорение везде, где это возможно.

Если OpenVG, OpenGL и OpenGL ES зависят от EGL, я думаю, что на мой вопрос можно ответить "да" или "нет". Просто имейте в виду, что вчера вечером я с головой погрузился в эту тему.

использует ли OpenGL или зависит от EGL?


вне темы, но нет тега EGL. А должно быть?

3 ответов


нет никакой связи между OpenGL и EGL. EGL обычно не работает на рабочих столах, и нет возможности создать контекст OpenGL рабочего стола через EGL.

контексты OpenGL вместо этого создаются и управляются специфичными для платформы API. В Windows используется API WGL. На платформах на базе X11 используется GLX. И так далее.

в прошлом году был некоторый шум от Khronos о создании версии EGL, которая могла бы работать на рабочем столе и создавать контексты OpenGL, но пока из этого ничего не вышло.


вы можете связать EGL_OPENGL_API как текущий API для вашего потока, через eglBindAPI(EGLenum api); последующий eglCreateContext создаст контекст рендеринга OpenGL.

С EGL spec, p42:

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

EGLBoolean eglBindAPI (eglenum api);

API должен указать один из поддерживаемых клиентские API, либо EGL_OPENGL_API, EGL_OPENGL_ES_API, или EGL_OPENVG_API

оговорка заключается в том, что реализация EGL хорошо в пределах своих прав не поддерживает EGL_OPENGL_API и вместо того, чтобы создать EGL_BAD_PARAMETER ошибка, если вы пытаетесь связать его.

также трудно связать с libGL, не поднимая AGL/WGL / GLX cruft; ABI на этих платформах требует, чтобы libGL предоставлял эти точки входа. В зависимости от того, на какой платформе вы играете, это может быть или не быть проблема.


использует ли OpenGL или зависит от EGL?

нет. Вы можете запустить OpenGL без EGL.

но возможно иметь реализацию EGL, способную создавать контекст OpenGL рабочего стола. Это потому, что EGL eglBindAPI (int api) позволяет EGL_OPENGL_API, EGL_OPENGL_ES_API или EGL_OPENVG_API.

но если вы спросите:

использует ли OpenGL-ES или зависит от EGL?

да, но есть are исключения.

В настоящее время (2015) у вас есть несколько реализаций OpenGL-ES, которые полагаются на EGL для создания графического контекста: Google ANGLE, PowerVR, ARM MALI, Adreno, AMD, Mesa и т. д.

но в последних выпусках NVIDIA и драйверы Intel вы также можете запросить контексты OpenGL-ES напрямую, где расширения WGL_EXT_create_context_es_profile и WGL_EXT_create_context_es2_profile доступны (Windows). То же самое на платформах Unix, где GLX_EXT_create_context_es_profile и GLX_EXT_create_context_es2_profile расширения доступны.

цель EGL-облегчить жизнь разработчиков, создав портативный и стандартный способ инициализации и получения контекста поддерживаемого графического API, не беспокоясь о платформе конкретные вопросы, такие как WGL, GLX и т. д. Это проблема разработчиков EGL, а не конечного программиста.