add Android support

[Andoryuuta]

From @slimsag on August 7, 2014 22:34

With Go 1.4 supporting Android and targeting game development generally, we should begin working towards supporting Android.

Copied from original issue: azul3d/oldissues#9

[Andoryuuta]

From @dskinner on August 8, 2014 0:8

Worth noting the following (which is in the golang-dev mailing list thread related):

• 1.4 is a goal but not a commitment by the Go team.
• Development can be tracked here https://code.google.com/p/go/source/browse/?repo=mobile
• The actual GLES bindings are up in the air, with a review of current OSS, but work will be done with renderscript as well for performance reasons.

[Andoryuuta]

From @slimsag on August 8, 2014 1:16

Good points! Here are a few of my own regarding Azul3D and Android:

• Even if Go does not officially support Android in 1.4, I intend to have it working before Go 1.5 is released (or whichever version comes after Go 1.4).
• I am closely monitoring the GLES bindings. There is high chance that we will not use those bindings, but instead use our own (native/gles). Batching of GL commands is one important reason for this.
• Renderscript I am not familiar with. From what I can tell it is Android's equivalent to OpenCL. We don't have any way to benefit from these API's as of yet.

[Andoryuuta]

From @dskinner on August 8, 2014 1:21

Point 2 and 3 I expected. From what little was mentioned regarding renderscript in the context of the android/go bindings, it sounded useful for things like generating textures on the fly and those api's may be use-able independent of the gles bindings, but only time will tell. Those may be things worth asking/pointing-out on the dev mailing list as go.mobile progresses.

On Thu, Aug 7, 2014 at 8:16 PM, slimsag notifications@github.com wrote:

Good points! Here are a few of my own regarding Azul3D and Android:

• Even if Go does not officially support Android in 1.4, I intend to have it working before Go 1.5 is released (or whichever version comes after Go 1.4).
• I am closely monitoring the GLES bindings. There is high chance that we will not use those bindings, but instead use our own (native/gles). Batching of GL commands is one important reason for this.
• Renderscript I am not familiar with. From what I can tell it is Android's equivalent to OpenCL. We don't have any way to benefit from these API's as of yet.

— Reply to this email directly or view it on GitHub https://github.com/azul3d/issues/issues/9#issuecomment-51553077.

[Andoryuuta]

From @crawshaw on January 3, 2015 17:19

I stumbled across this issue while searching for information about GL batching, I was hoping you could enlighten me.

I understand why this would be a significant issue in OpenGL 1.x, which is driven by a large number of function calls, but it seems to me that the most efficient form of batching in the shader world is actually to merge draw calls. Do you still end up with enough function calls that the cgo boundary is expensive enough to notice on a mobile device?

If so, I would be open to exploring a batching implementation inside golang.org/x/mobile/gl. I don't think any API changes are necessary, a batch queue could be built underneath what's there. But before doing so, I'd need an example program that would benefit from it, so I could measure the performance improvement.

[Andoryuuta]

From @dskinner on January 3, 2015 17:41

@crawshaw until @slimsag gets back to you, he put together a benchmark specific to batching that you can look over here that he'll likely elaborate on for you: https://github.com/slimsag/cgo-batching

and related discussion: https://github.com/azul3d/issues/issues/17

[Andoryuuta]

From @slimsag on January 3, 2015 20:42

@crawshaw

Thank you for commenting here -- the situation has changed since I last posted here back in August.

I stumbled across this issue while searching for information about GL batching, I was hoping you could enlighten me.

For nearly 90% of the work you are doing with OpenGL ES 2 era hardware, grouping together draw calls will benefit you the most.

I understand why this would be a significant issue in OpenGL 1.x, which is driven by a large number of function calls, but it seems to me that the most efficient form of batching in the shader world is actually to merge draw calls. Do you still end up with enough function calls that the cgo boundary is expensive enough to notice on a mobile device?

As @dskinner did put, call batching is not fictional in the sense that it does have measurable performance gains -- but as of today there isn't an application that suffers from this. For this reason we've already switched to Glow's OpenGL ES 2 bindings (github.com/go-gl/glow).

I think your bindings are more clean and albeit more idiomatic Go -- but we also use Glow for (desktop) OpenGL 2 bindings and it would be easier to add CGO call batching to one set of bindings rather than two individual ones, should the need arise.

If so, I would be open to exploring a batching implementation inside golang.org/x/mobile/gl. I don't think any API changes are necessary, a batch queue could be built underneath what's there. But before doing so, I'd need an example program that would benefit from it, so I could measure the performance improvement.

I think if we did find a situation in which an application is severely hindered by this, it would be worth looking into improving this in CGO itself. It is not strictly an OpenGL problem but rather a CGO overhead cost, due to the fact that Go and C use different (and incompatible) calling conventions. Go's calling convention probably cannot be changed to match the C one, but perhaps CGO could feature implicit or explicit call batching.