Исходные файлы OpenGL ES

Question

Я пытаюсь создать OpenGL SO lib из источников android (libGLESv2.so), и мне хотелось бы немного лучше понять внутренний механизм Android OpenGL ES и поток.

Пожалуйста, исправьте меня, когда я ошибаюсь: Я знаю, что в windows разработчик включает gl.h и статическую ссылку на OpenGL32 (64) .lib (которые, в свою очередь, динамически ссылаются на OpenGL32.dll (возможно, есть способ для динамической ссылки на OpenGL32.dll разработчиком, но это не важно). Разработчик подвергается декларации OpenGL API, но реализация, которую я предполагаю зависящей от HW.

В том же сценарии Android: предполагается, что разработчик import .opengl.GLES20 и вызывает следующий метод: GLES20.glTexEnvf (.... Хотелось бы узнать, что происходит за кулисами в Android (возможно, Linux лучше для новичков Android). t реализация, которая находится в источнике opengl/java/android/opengl/GLES20.java, вызывает встроенную функцию C glTexEnvf, которая, в отличие от окон, у нас есть ее реализация, которая находится в opengl/libagl.

Это правда? В любом случае, что такое библиотека GLES2_dbg в/libs/GLES20_dbg? я вижу там какую-то реализацию отладки с скриптами python ... они должны скомпилировать отладочную версию OpenGL? Каковы файлы .in и файл gl2.cpp в/libs/GLES20? Где звонки HW? каждый поставщик графического процессора отправляет свою реализацию libGLESv2 для вызовов HW, поскольку я видел libGLESv2_adreno200.so в моей дуге xperia?

Пожалуйста, помогите мне понять поток. Если у вас есть ссылка, которая объясняет эту структуру даже в Linux, это будет здорово.

Answer 1

В Windows opengl32.dll содержатся как резервные резервные копии растеризатора, так и так называемые батуты в доставке OpenGL-ICD с драйвером GPU.

opengl32.lib is not действительно библиотека, но перекрестная ссылка для компоновщика для добавления записей в исполняемый файл, которые заставляют ОС динамически связывать программу с DLL во время выполнения.

В Linux в текущей реализации libGL.so поставляется с графическим драйвером и содержит конкретные реализации поставщика. Компиляторы, используемые в системах * nix, не полагаются на дополнительную перекрестную привязку .lib, но могут принимать информацию непосредственно из .so

На Android libGLES, который вы видите, является лишь своего рода заполнителем, чтобы сделать возможной связь. Но в конечном итоге поставщик GPU предоставляет правильную библиотеку, которая попадает туда, где проживали фальшивые libGLES.

В .IN-файлах нет ничего особенного. Это входные файлы, используемые системами конфигурации и сборки для создания исходных файлов из шаблона (файл .in) с полями, заполненными значениями конфигурации.

Answer 2

спасибо за быстрый ответ, я сделал немного больше копания и, как я увидел здесь: Missing OpenGL drivers on Android emulator, дальнейшие пояснения.

Теперь я понимаю, что libagl - это чистая реализация SW.

В этом случае libhgl фактически является реализацией поставщика графического процессора.

Я также понял, что libEGL открывается (нашел его в коде - Loader.cpp) libGLESv2 .... Так я буду просить больше 2 вопрос:

1. libGLESv2 только динамически ссылку на Lib HW или libEGL делает это? (Нашли что-то на EGL - loader.cpp, который, кажется, как динамически связать OpenGL API,)

2.So, когда я называю OpenGL API я иду корыто libEGL (поскольку является обязательным динамическим)? и оттуда в libGLESv2?

благодарит за вашу помощь Теперь это начинает иметь смысл