Is it viable to use glow to generate an interface with multiple backends?

[dmitshur]

Hi @errcw (/cc @ajhager, @slimsag),

You might've seen me mention you in the discussion at https://github.com/ajhager/webgl/pull/2.

I'm starting to wonder if it would be possible and viable to use glow (possibly with some degree of modifications to allow for this) to generate an interface with multiple backends.

For example, https://github.com/ajhager/webgl currently provides (sorry about the misleading repo name) a webgl-like API that actually has 2 backend implementations:

• WebGL
• OpenGL 2.1

After thinking about it, it seems a better approach would be to use the OpenGL ES 2 spec as the interface, and provide those 2 backends (and possibly more).

Do you think glow can be useful here? Feel free to ask any questions about this if you want me to elaborate or explain. Thanks!

[bryanturley]

I have thought about doing that myself, I don't think it would be very hard for Glow to output that. The reason I am not is https://www.opengl.org/registry/specs/ARB/direct_state_access.txt Nearly all of the DSA funcs could use go receivers making the opengl api feel a little more go.

Older direct state stuff could be folded in as well. gl.UseProgram(progID) could be progID.UseProgram()

gl.AttachShader(progID, shadID) progID.AttachShader(shadID)

Think go.mobile was contemplating that as well.

[dmitshur]

Nearly all of the DSA funcs could use go receivers making the opengl api feel a little more go.

I have not completely made up my mind about this, but so far I think I prefer the OpenGL APIs being more consistent with the upstream APIs and not more idiomatic Go. Given that the vast majority of OpenGL code out in the wild (and my previous projects) are using C++, it makes translating easier when you don't have to think about if a given OpenGL func in Go has been changed to have a receiver, etc.

Think go.mobile was contemplating that as well.

Do you happen to have a link to where where it was being discussed?

[dmitshur]

There is a gl package in x/mobile:

http://godoc.org/golang.org/x/mobile/gl

Package gl implements Go bindings for OpenGL ES 2.

The bindings are deliberately minimal, staying as close the C API as possible. The semantics of each function maps onto functions described in the Khronos documentation:

https://www.khronos.org/opengles/sdk/docs/man/

One notable departure from the C API is the introduction of types to represent common uses of GLint: Texture, Surface, Buffer, etc.

It seems to be a pure OpenGL ES 2.0 binding (single backend).

Does anyone know what platforms OpenGL ES 2.0 is actually available/usable on as of 2014? Clearly, Android is one of them, but what about desktop OSes? I see mentions of linux and darwin in the gl.go #cgo declarations. I think that OpenGL ES 2.0 might be available on Linux, but I don't think it's available on OS X, is it? (It's definitely not available in browsers; only WebGL is; of course it's very similar.)

Edit: The only resources I have on this topic are:

• http://www.g-truc.net/post-0457.html
• http://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_2.0_2.

Some of the TODOs of that package are:

// TODO(crawshaw): build on more host platforms (makes it easier to gobind).
// TODO(crawshaw): expand to cover OpenGL ES 3.

(/cc @crawshaw if you have a moment to read this, feel free to share comments if you have any.)

[bryanturley]

Anything that supports GL4.1 is API compatible with GLES2.0. GLES3.0 -> GL4.3 GLES3.1 -> GL4.5

When they made gles2.0 they started around gl3.2 core and stripped out features. The only API differences were a few funcs that took float32 instead of float64, they added the float32 versions to GL4.1.

Now the default settings and some corner case behaviors in the context may be different so you have to build an appropriate context. You could use glow's gl4.1 binding as a gles2.0 binding on desktop gl right now.

A failed? patch I submitted to go.mobile a tincy bit ago makes it more broadly usable on desktop gl in linux https://go-review.googlesource.com/#/c/1851

Read these for more info, also search for GLES in the official gl4.1/gl4.3 and gl4.5 spec pdf files https://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt https://www.opengl.org/registry/specs/EXT/glx_create_context_es2_profile.txt

On the receiver's thing... I can't remember where it was mentioned but I credit them with the idea. I was being annoying and/or helping as they created it early on.

[bryanturley]

Oh wait... that is a precursor for the patch I would submit when it gets resolved nevermind on that. Think people are shut down for xmas.

[bryanturley]

I should note the strongest reason for doing this would be windows. If you have mutliple gpus of different families/vendors the pointers you get from wglGetProcAddress() may be different per context. I have never been there though so not 100% sure about that.

[errcw]

Glow has roughly the right structure to allow multiple backends. At a minimum you'd have to refactor the templates and change the Init signature. Some pieces would require more careful rearrangement such as the debug callback. But I agree in general there is a non-trivial amount of code that could be reasonably reused. I'd be happy to review a patch but my bandwidth for writing it myself is quite limited for the next quarter or two.

[dmitshur]

Thanks for the overview Eric. This won't be my highest priority at the moment, but it's something I may want to come back to at some point.

It seems the potential is promising.

[einthusan]

Okay, its 2021. There are many projects out there trying to provide GLES2 with desktop development support by translating GLES2 to OpenGL/Metal/etc. Such projects are (at least for mac);

golang/x/mobile/gl
ANGLE
MoltenGL

I am trying to figure out how to tell glow to link to ANGLE for example. I stole the libs libEGL.dylib and libGLESv2.dylib from Google Chrome because I couldn't compile ANGLE on my outdated OS (El Capitan 10.11.6).

I am also curious as to why glow has an -api flag that can take either gles or egl ... i thought egl was the de-facto way to complement gles? Does glfw (go-gl/glfw) somehow supersede egl? I see that it is possible to write the following code with glfw ...

// use OpenGL ES v2.0
glfw.WindowHint(glfw.ContextCreationAPI, glfw.EGLContextAPI)
glfw.WindowHint(glfw.ContextVersionMajor, 2)
glfw.WindowHint(glfw.ContextVersionMinor, 0)
glfw.WindowHint(glfw.ClientAPI, glfw.OpenGLESAPI)

@dmitshur if you can take a moment to clarify this for me, as well as for everyone else, it would be much appreciated!

EDIT: more info about this @ https://github.com/johanhenriksson/goworld/issues/22#issuecomment-766288275