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

Question

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

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

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

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

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

Answer 1

В Windows opengl32.dll содержит резервный программный растеризатор и так называемые батуты в поставку OpenGL-ICD с драйвером графического процессора.

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

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

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

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

Answer 2

спасибо за быстрый ответ, я немного покопался и, как я увидел здесь: Отсутствуют драйверы OpenGL на эмуляторе Android , дальнейшее объяснение.

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

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

Я также понял, что libEGL открывает (нашел его в коде - Loader.cpp) libGLESv2 .... Поэтому я задам еще 2 вопроса:

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

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

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