Building Dolphin and other OpenGL programs for Android?

[xperia64]

I've looked around and am still pretty confused on how to build native OpenGL code for the Tegra K1 and set up a valid surface.

Which library do I link to, how would I load it, and where is the GL/gl.h header?
According to Dolphin's logcat, it loads libGLESv1_cm, and that doesn't seem right.

I've downloaded the Nvidia's TADP, and couldn't find anything useful in that respect.

[KHg8m3r]

Not familiar on how to build for yourself, but you can get the latest Android builds from here: https://buildbot.dolphin-emu.org/builders/release-android

[xperia64]

I'm aware of that, but I want to compile other OpenGL things like mupen64plus video plugins. Dolphin is the only open-source app I could find for the Tegra K1 that uses OpenGL, so I thought I'd ask here.

[Sonicadvance1]

Now this one is a fun topic to do. We don't actually directly link to EGL, libGLESv1_cm or libGLESv2. We only indirectly link against libEGL through libAndroid and it's dependencies.
Of course a typical application if it wants GLES 1.1 it'll link against libGLESv1_cm, if it wants GLES 2.0 or 3.0 it'll link against libGLESv2 or in some cases libGLESv3.
OpenGL support on Android is a bit different in this regard. Android doesn't and won't ever provide a libGL to link against like on regular systems. So you have to grab all of your function pointers manually. This isn't too big of a deal since with regular OpenGL you're expecting to do this anyway and you usually have a library like GLEW to do it for you.
The main difference is that GLEW expects you to link directly against OpenGL 1.1 to 1.3 function pointers provided by a libGL library. These are the only functions that /should/ be exported by a proper libGL library. Although Windows is the only vendor I know of that does this correctly.
So you need a different library to pull in all of your OpenGL function pointers that includes the 1.1-1.3 core function, and it'll be pulling these in from your EGL context with eglGetProcAddress. Dolphin gets around this by doing this by itself instead of having a library do it, which is pretty crap and we're waiting for libepoxy to shape up a bit before dropping it entirely.
Speaking of libepoxy it is basically what you want since it support GLES and GL along with Android support. The only downside is its OS X and Windows support is quite lackluster.

As for generating a desktop OpenGL context, it isn't too terribly difficult. First you check if it exposes the EGL_RENDERABLE_TYPE bit for desktop OpenGL. Then you create a context with that and also have to call eglBindAPI with the desktop opengl bit.

[Nintonito]

(11-03-2014, 02:41 AM)Sonicadvance1 Wrote: Now this one is a fun topic to do. We don't actually directly link to EGL, libGLESv1_cm or libGLESv2. We only indirectly link against libEGL through libAndroid and it's dependencies.
Of course a typical application if it wants GLES 1.1 it'll link against libGLESv1_cm, if it wants GLES 2.0 or 3.0 it'll link against libGLESv2 or in some cases libGLESv3.
OpenGL support on Android is a bit different in this regard. Android doesn't and won't ever provide a libGL to link against like on regular systems. So you have to grab all of your function pointers manually. This isn't too big of a deal since with regular OpenGL you're expecting to do this anyway and you usually have a library like GLEW to do it for you.
The main difference is that GLEW expects you to link directly against OpenGL 1.1 to 1.3 function pointers provided by a libGL library. These are the only functions that /should/ be exported by a proper libGL library. Although Windows is the only vendor I know of that does this correctly.
So you need a different library to pull in all of your OpenGL function pointers that includes the 1.1-1.3 core function, and it'll be pulling these in from your EGL context with eglGetProcAddress. Dolphin gets around this by doing this by itself instead of having a library do it, which is pretty crap and we're waiting for libepoxy to shape up a bit before dropping it entirely.
Speaking of libepoxy it is basically what you want since it support GLES and GL along with Android support. The only downside is its OS X and Windows support is quite lackluster.

As for generating a desktop OpenGL context, it isn't too terribly difficult. First you check if it exposes the EGL_RENDERABLE_TYPE bit for desktop OpenGL. Then you create a context with that and also have to call eglBindAPI with the desktop opengl bit.

Is this a process that would be standard, or reasonably similar for ANY app that intends to use the extended desktop featureset for the K1? I feel like this is something nvidia would have released a toolkit for, since nobody has done this before them.

[Sonicadvance1]

It is something that any application will need to go through that will be using desktop OpenGL.
Any regular application could probably get away with just using libepoxy since they've accepted my patches towards Android support.

[xperia64]

Sorry for being bit of an idiot, but how exactly would I build libepoxy, given that it uses automake and appears to generate headers based on the system?

[Sonicadvance1]

pregenerate the headers, build the library as a static library using a custom build system, and statically link it in.
That's what Dolphin will be doing in the future for libepoxy.