My original cgo bindings took 4 minutes to compile with go (WITH GO).
That was on tip between 1.1 and 1.2.
4 minutes! go compile times really spoiled me so I had to fix this ;)
I did a bunch of things to make the source smaller that should also help glow.
Especially since the core 4.4 package compiles into a 13MB .a file.

https://github.com/bryanturley/old_gl/blob/master/core/funcs.go#L1178
Scroll to the very end of that line. You will see // 14
That means those 14 opengl functions share that function signature.
Which in turn means you can turn 14 bridges into 1.
The only downside to that is you get semi-ugly looking unnamed bridge functions.
In this example the type bgl003_t is only used with the function bgl003 (3 hex digits)
https://github.com/bryanturley/old_gl/blob/master/core/funcs.go#L326
The go side of those 14 functions all call bgl003 with their own function pointer (of type bgl003_t), since they all share the same function signature.
https://github.com/bryanturley/old_gl/blob/master/core/funcs.go#L4860 <-- one of the bgl003

I think this shrunk my source files 40-60% and should make a significant impact on your library size.

Would this be something that should be fixed here, instead of in github.com/go-gl/gl?

go-gl/gl#31

When using mutliple Glow packages, cgo compilation encounters name collision errors as a result of declarations duplicated across packages. Naive fix suggestion: add a package-specific suffix to the function name to avoid the errors.

I am experiencing a weird problem where my code works fine on 3 of my test machines (OS X 10.7, 10.8 and linux) but not on a machine with OS X 10.6. The problematic machine can't compile any GLSL shader, it seems to always return gl.FALSE when asking for gl.COMPILE_STATUS. What is especially odd is that the info log is always empty, even if i introduce obvious errors in the source. Normally there will be useful messages in the info log when a compilation fails. The problematic machine is able to compile and link and run the very same shader just fine from my (original) C++ application. If I 'mess up' the shader source there, I do get sensible info log data back, so in principle, that machine can do what i want it to do...
The only other external package that my application depends on is glfw3.

What could be going on here? Could it be a glow/gl issue?

What is bothering me most is that the C++ code is doing the very same thing as the Go equivalent, and that the very same code works on 3/4 of my test machines...

This is the function I use to compile a shader:

func GLSL_Compile(name string) (uint32, error) {
    fmt.Fprintf(os.Stderr, "GLSL_Compile(%s)\n", name)

    // check source file type by extension
    var shaderType uint32
    ext := path.Ext(name)
    switch ext {
    case ".vshader":
        shaderType = gl.VERTEX_SHADER
    case ".fshader":
        shaderType = gl.FRAGMENT_SHADER
    default:
        return 0, fmt.Errorf("not a GLSL shader source file: '%s'", ext)
    }
    // open source file
    file, err := os.Open(name)
    if err != nil {
        return 0, fmt.Errorf("os.Open(): %s", err)
    }
    defer file.Close()
    // read data
    source, err := ioutil.ReadAll(file)
    if err != nil {
        return 0, fmt.Errorf("ioutil.ReadAll(): %s", err)
    }
    source = append(source, 0) // zero terminate string
    int8s := bytesToInt8s(source)
    // compile
    shader := gl.CreateShader(shaderType)
    sourcePtr := &int8s[0]
    length := int32(len(source))
    gl.ShaderSource(shader, 1, &sourcePtr, &length)
    gl.CompileShader(shader)
    info := GLSL_ShaderLog(shader)
    // check compile status
    var status int32
    gl.GetShaderiv(shader, gl.COMPILE_STATUS, &status)
    if status == gl.FALSE {
        gl.DeleteShader(shader)
        return 0,
            fmt.Errorf("Compile status: failed...\nInfo Log:\n%s\n", info)
    } else if len(info) > 1 {
        fmt.Fprintf(os.Stderr, "Compile Info Log:\n%s\n", info)
    }
    return shader, nil
}

Who can shed a light on this?

I just had a try at building GLES2 bindings using GLOW on Windows:

> %GOPATH%/bin/glow generate -api="gles2" -version="2.0"
2015/04/01 16:06:54 error generating package:exit status 1

It does however, look like it built all the files:

> ls gl
conversions.go  debug.go  package.go  procaddr.go

I get the same error trying to build GL. I guess I'll find out soon enough if the content of those files is broken.

While it is possible to achieve type safety for constants passed to GL functions, I think it would be a breaking change.

What I ask for is to declare a type, e.g. type GLConst int32 and define constants as

const (
	ACTIVE_ATOMIC_COUNTER_BUFFERS GLConst = 0x92D9
	ACTIVE_ATTRIBUTES             GLConst = 0x8B89
	ACTIVE_ATTRIBUTE_MAX_LENGTH   GLConst = 0x8B8A
        ...
)

Then it would be possible to use stringer to generate the code which would convert a value (returned by gl.GetError, for example) to constant name. I think it would be pretty neat for debugging and exception displaying

go vet gl-core/all/gl/*

gl-core/all/gl/conversions.go:39: possible misuse of unsafe.Pointer
gl-core/all/gl/conversions.go:46: possible misuse of unsafe.Pointer

False positive? Asking the go vet author in this thread may help:
https://groups.google.com/forum/#!topic/Golang-nuts/FAOZoQzodAI

Russ:
"Run go vet on your code. If it's happy, your code is fine. If not, your code is probably NOT fine."

I reported an issue 7 months ago, no one comment on it. Is this still maintained?

The github.com/go-gl/mathgl package is actively maintained, widely used, and OpenGL-focused, so represents a better choice for Glow.

This is a simple cleanup task. It's a good first contribution for anyone interested in taking it.

In #87, GlowGetProcAddress was given a per-package unique suffix to fix go-gl/gl#85.

In go-gl/gl#85 (comment), @errcw realized that:

In retrospect it occurs to me that an equivalent fix might have been to mark the C functions as static (which, I realize now, is why the GL definitions do not experience the same conflict)

Since that approach is slightly simpler, we can update our code to use it.

This command:
./glow generate -api=egl -version=3.1
Fails with this message:
2016/01/30 17:49:24 unable to generate package: &{egl 2.0 my_home_folder/go/src/github.com/go-gl/glow/tmpl .* $^ false}

OS: Debian stretch

If I understood the README correctly, this should generate ES 3.1 bindings.

GoStr receives an *uint8, shouldn't Str return an *uint8 too?

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

You might've seen me mention you in the discussion at ajhager/webgl#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!

Hi,

I was using https://github.com/go-gl/gl bindings and I saw that EXT_texture_filter_anisotropic is not exposed when using the core profile. I report this there, but it seems that this is glow related. I guess that this is expected behavior.

However, I don't understand a few things. Firstly, why did you remove extensions from the core profile? After reading https://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts I think that extensions are not marked as deprecated, some old "core" functionality is.

So, there are 3 options: use the compability profile with all extensions included, use the compability profile with some extensions excluded as the user excludes them, and use the core profile without any extensions (I don't think that extensions included in core OpenGL should count as an extension). I don't understand why a fourth option (core+extensions) can be used.

Moreover, I think that this fourth option is the better way to go. Removing deprecated functionality (like fixed pipeline) is normally the best option, and I guess that most people will agree with me in that. However, removing all extensions from the core profile is not good at all. There are extensions that provides really useful functionality and that are implemented everywhere, see https://www.opengl.org/wiki/Ubiquitous_Extension . Using OpenGL without anisotropic filtering in 2016 seems plainly wrong to me, this extension was made in the 1999, all AAA games provides it, it is very easy to use and it improves image quality. Moreover, there is no possible good workaround to this since using texelFetch will mean an important performance loss (and implementing anisotropic filtering in a shader won't be an easy task either).

Maybe you don't want to include all extensions on the core profile by default, but at least I think that an option to include extensions should exists.

Finally, I think that this should be documented in the Readme since "remext: A regular expression describing which extensions to exclude. Empty by default, excluding nothing. Takes precedence over explicitly added regular expressions." gives the impression that all extensions are included by default on both profiles.

Hello. Will glow support Vulkan, or not?

How to use multiple extensions for Glow?
I tried | seperator, now works!

Because C functions cannot call back to Go functions via function pointers we need to implement special-case support for the debug callback. I previously investigated this support in the context of GoGL2 and sketched out the following design.

Roughly, the C code looks like:

extern void GlowDebugCallback(...);
void APIENTRY glowCDebugCallback(...) {
  GlowDebugCallback(source, type, id, severity, length, message, userParam);
}
void glowDebugMessageCallback(PGLDEBUGMESSAGECALLBACK glfptr, GLDEBUGPROC callback, const void* userParam) {
    (*glfptr)((GLDEBUGPROC)glowCDebugCallback, userParam);
}

And the Go code:

func DebugMessageCallback(callback DebugProc, userParam uintptr) {
    userDebugCallback = callback
    C.glowDebugMessageCallback(pDebugMessageCallback, (C.GLDEBUGPROC)(callback), userParam)
}

var userDebugCallback DebugProc
func GlowDebugCallback(...) {
  if (userDebugCallback != nil) {
    userDebugCallback(...)
  }
}

All of your core packages are full of extensions to deprecated things.
They also have vendor extensions, which are definitely not core.
Even ARB and EXT extensions aren't core.
OES extensions (which means [O]penGL [ES]) shouldn't be in GL either.

ColorTableEXT <-- paletted color in core opengl???
a number of extensions for changing Lights that don't exist in core (anymore).

There is also an alias tag in the xml files that indicate an extension func is the same as a core func.
In your core packages you could weed out all extension funcs that have been made core at 3.2.
I do this (probably to a fault) in my bindings.

For instance

       <command>
            <proto>void <name>glActiveTextureARB</name></proto>
            <param group="TextureUnit"><ptype>GLenum</ptype> <name>texture</name></param>
            <alias name="glActiveTexture"/>
        </command>

I ignore the existence of glActiveTextureARB entirely since it has an alias that doesn't end in an extension suffix. I do this because you really cannot easily port a c based opengl program to go, therefore we have nothing legacy to support with gl in go.

The synopsis of generated packages is quite ugly, for example:

http://i.imgur.com/80f2lVC.png

Perhaps it would be better to just say something like:

Package gl implements Go bindings to OpenGL version 2.0.

This package was automatically generated using Glow:
    http://github.com/go-gl/glow

Generate the OpenGL 2.0 wrappers using:
glow generate -api=gl -profile=core -version=2.0 -xml=xml/

Build them and you will get something like:

$ go install tmp/gl-core/...
# tmp/gl-core/2.0/gl
gl-core/2.0/gl/package.go:8220:5: expected declaration, found 'IDENT' store
gl-core/2.0/gl/package.go:10370:24: rune literal not terminated
gl-core/2.0/gl/package.go:10375:26: rune literal not terminated
gl-core/2.0/gl/package.go:11057:24: rune literal not terminated
gl-core/2.0/gl/package.go:11062:26: rune literal not terminated

Further inspection shows that the PackageFunction's Doc strings sometimes (not often) contain newline characters in them. For instance:

// creates and initializes a buffer object's data
    store
func BufferData(target uint32, size int, data unsafe.Pointer, usage uint32) {
  C.glowBufferData(gpBufferData, (C.GLenum)(target), (C.GLsizeiptr)(size), data, (C.GLenum)(usage))
}

I am using go-gl/gl, and receiving the following compilation errors
undeclared name: GL_TEXTURE_CUBE_MAP.
This error persists with some other symbols such as GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_DEPTH_COMPONENT etc.

If I understand it correctly, this is related to #77 and these symbols belong to the extensions described by glext.h for older versions of OpenGL (prior to 3.2), or glcorearb.h for a newer stuff.

However, contrary to what I believe should happen according to #77, I do not get them loaded automatically if I import OpenGL via "github.com/go-gl/gl/v4.1-compatibility/gl" or "github.com/go-gl/gl/all-core/gl" instead of the "github.com/go-gl/gl/v4.1-core/gl" profile.

It seems the only place where I see glext.h under the go-gl umbrella is here:
https://github.com/go-gl/glfw/tree/master/v3.1/glfw/glfw/deps/GL/glext.h
However, it has GL_DEPTH_COMPONENT16 and many more instead of a simple GL_DEPTH_COMPONENT.

The only place where I could find GL_DEPTH_COMPONENT in the context of Go was this engine code and the file
https://github.com/g3n/engine/blob/master/gls/glcorearb.h

Did any of these files once belong to go-gl/glfw version 3.1 and got somehow deprecated/removed from go-gl's glfw version 3.3? Could someone explain me how to load any/all extensions so that they are visible in go-gl, do they belong to glfw, gl or glow folders/projects?

For now my solution is to simply apply glapi2go from
https://github.com/g3n/engine/tree/master/gls
with a modification inside glapi2go/main.go:

``
// gldef2go converts a name such as GL_LINE_LOOP to LINE_LOOP
func gldef2go(gldef string) string {

//return strings.TrimPrefix(gldef, "GL_")
return gldef

}
``

so that the preix GL_ is not dropped. This main.go creates the file consts.go which I then place in my own project. However, it seems be some hacky acrobatics around what should be quite a common case dealt with go-gl.

Another related question, albeit less important is this. The OpenGL constants such as GL_DEPTH_COMPONENT become automatically exported/visible to all the other Go modules outside automatically due to the Go's capitalization rule, is this potentially a problem, would you suggest decapitalizing them? Which convention should be stronger, that of Go, or OpenGL?

Users currently need to build their own Glow packages, but it would be convenient to have prebuilt packages including most relevant use cases.

I just installed go 1.4 on windows and now my really small glow project takes 19.6 seconds to compile instead of 1.

Am I the only one?

Investigate whether all APIs at a minimum compile and can be initialized.

Now that package glt is unlikely to contain shared types (e.g., type Enum uint32) there is no reason why the helper funcs cannot be pushed to the generated package code. This transformation would simplify the use of the generated code.

Running on ubuntu linux 64-bit, the command 'go install ./gl-core/3.3/gl', returns the following error:

procaddr/glx/glx.go:10: cannot convert _Cfunc_CString(name) (type *_Ctype_char) to type *_Ctype_GLubyte

Currently .gitignore skips including the xml/ directory. We should instead include in the repository the XML files used to generate the prebuilt packages to ensure they are reproducible.

OS: Windows 10

There is a problem with glow. I followed all the steps mentioned in the README and everything was ok till glow download. The script runs and asks for Github credentials but fails everytime. I checked my credentials and tried about 10-15 times, but no success.

Please help me in setting up OpenGL.

Right now glow requires the context version to be known at compile-time. This is undesireable due to a possible need to dynamically determine supported features at runtime. It also makes a higher-level wrapper such as go-gl/gl to be written, since it, too, would have to have the context known ahead of time.

My proposal is the concept of an engine, this is inspired by goblas's method of handling blas bindings. While this is different since BLAS is a single API and not multiple versions of GL, but I think the same general principle can apply.

The idea is to have a single package, say glow/glengine dedicated to several interfaces such as,
type Core33 interface {
// functions in GL core 3.3
}

In addition, each package will define an empty struct, for instance:

// in the core 3.3 wrappers

type Context struct{}

func (_ Context) GenBuffers(/* parameters here */) {
    GenBuffers(/* call */)
}

The biggest problem with this is requiring a type switch for each call in user code, so I also propose the following interface/struct pair be defined

type GLEngine interface {
    // Every GL method from every version
}
/* Back in Core 3.3 */
type GLEngine struct {}

   func (_ GLEngine) GenBuffers(/* parameters here */) {
    GenBuffer(/* call */)
}

func (_ GLEngine) MatrixMode(/* blah blah */) {
    panic("MatrixMode not supported in GL Core 3.3")
}

How does this help? Consider a hypothetical higher-level wrapper like go-gl/gl

package gl
// ...
import "github.com/errcw/glow/glengine"

var gl glengine.GLEngine

func Init(engine glengine.GLEngine) error {
    if !engine.Init() {
        return errors.New("Cannot initialize GL engine")
    }

    gl = engine
    return nil
}

// Will panic with a clear Go stack trace and error if function is not implemented
func GenBuffer() Buffer {
    buf := Buffer{}
    return Buffer{gl.GenBuffers(1, unsafe.Pointer(&buf))}
}

So from a user perspective, the higher-level wrapper is initialized by passing it a specific glow-generated context, but all of the ugly package management nonsense can be abstracted out into a single initialization file, and the higher level wrapper doesn't need to be privy to things like context versions.

There is a downside that people would need to benchmark: while the option to use glow at the package level should always remain, using the interface does require dynamic dispatch. This is, IMO, a fair tradeoff and one that each user and higher-level package writer can make for themselves. While I mentioned go-gl/gl a few times here, that was in example, I expect them to continue using GLEW, but I sincerely think that providing such abstraction would increase the usability of the package in higher level wrappers and real applications without complicating the generator much at all.

In Go 1.3 the new GC is precise when examining the stack. As a result it is not safe to store pointer values in uintptr-typed variables. Glow's use of uintptr to accept arbitrary pointer types should be switched to unsafe.Pointer. Separately the conversion helper functions should be scrubbed to ensure they will work correctly with the new GC behavior.

For the record I originally chose uintptr as the type to avoid requiring glow users to depend on the unsafe package.

We can't run glow outside of the package directory because it tries to load relative template files. Obviously it's not a big deal, but I thought it was a bit annoying and could be fixed by resolving the template files relative to $GOPATH.

When I did glow download in #89, it fetched the latest XML from our current source at https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml:

$ glow download
2017/11/09 19:51:41 Downloading https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
2017/11/09 19:51:41 Downloading https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml
2017/11/09 19:51:41 Downloading https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/egl.xml
2017/11/09 19:51:41 Downloading https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
...

However, even the latest version of that repository, at this moment, does not yet contain definitions for OpenGL 4.6. It contains 4.5 as the latest version.

The alternative source at https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml that @kjozic found contains 4.6.

We need to decide what to do to add support for OpenGL 4.6 to glow:

1. Do we wait until the current source adds 4.6? Any way to find out when that will happen?
2. Do we change the default source where we fetch our XML files? But what about the doc XML files and egl.xml which isn't present in https://github.com/KhronosGroup/OpenGL-Registry/tree/master/xml?

/cc @errcw Need your input on this decision.

Hi,

Would you consider adding a prebuilt package for OpenGL 2.1 to this repo?

It's the latest version that still has the immediate mode, which I (embarrassingly enough) still use, simply because it's so much faster to make prototypes with (as long as you don't hit the performance wall).

That way, I could use glow directly from github.com/errcw/glow/gl/2.1/gl.

Otherwise, I'll have to host it at github.com/shurcooL/glow/gl/2.1/gl.

Thanks.

OpenGL 4.5 was officially released. Glow should offer prebuilt packages for version 4.5.

This issue made because go-gl/gl#18 is the wrong repository for it.

This is the exact same issue that had to be resolved back in the old bindings go-gl/glfw#78, the most straightforward fix would be to work with uintptr instead of unsafe.Pointer. Using a new type instead of uintptr is also viable, but in no circumstance should it stay in an unsafe.Pointer

E.g. in the last xml update is a typo:
capnm/Khronos_XML_API@551e695#diff-31483b2c6dcd3df2b1bc9904e19c5cafR1955

I guess there are more or will be more such bugs in the future.
How to handle this? Where to report bugs? Make a comment in README or wiki entry? Etc.

The code seems to be very similar to
http://tomdalling.com/blog/modern-opengl/03-matrices-depth-buffering-animation/

Just wondering if you've considered adding Vulkan API binding generation support? I know it's not precisely OpenGL, but the binding generation should work almost the same way given the source for the APIs is the same, and having Go support for this new high performance API would be really useful for GPU computing purposes.

Now that the glow-generated bindings have been moved to go-gl/gl repo (see go-gl/gl#1), we need to make some follow up PRs for glow:

• Add a removal notice to warn than the gl bindings import paths have changed and will be removed in 30 days as per the document. Similar to go-gl/glfw#1.
• Make changes to glow to allow it to generate the new bindings with changed import paths. Ideally, I think we should be able to generate the gl bindings from the gl repo by doing go generate.
  • Open PRs #56 and go-gl/gl#9 to resolve this task.
• Actually remove the gl bindings in 30 days.

I've read the announcement and was eager to test the new bindings. Unfortunately I am not that happy with the new API. For example, take a look at:

// Replaces the source code in a shader object
func ShaderSource(shader uint32, count int32, xstring **uint8, length *int32)

I do not mind if ShaderSource is a method (like before) or a function, but working with this signature within Go is extremely cumbersome and error-prone and I had to look up the C documentation to understand the parameters. Something like ShaderSource(shader uint32, sources []string) or type Shader uint32; func (s Shader) Source(sources []string) would be definitely better.

Are there plans to improve the generated bindings? It might be necessary to add additional annotations to guide the automatic generation.

In the most recent version of gl.xml the function glPathGlyphIndexRangeNV declares one parameter as GLuint baseAndCount[2]. Glow utterly fails at generating correct C or Go code for this case. It uses GLuint [2] as the C type and uint32 as the Go type, neither of which is appropriate.

Per Go Issue #8310 we may be prevented from having Go pointers cross the C boundary. Allowing Go pointers to be used by the OpenGL C functions is core functionality for Glow so we should track the progress of this issue and prepare for whatever implementation Go builds.

Following @bryanturley's lead Glow should consider offering "sanitized" packages with a friendlier API. As a first pass I expect two things. One, including only relevant, high-quality extensions. Two, providing functions that use the OpenGL parameter length information (e.g., transforming gl.BindSamplers(first uint32, count uint32, samplers *uint32) to gl.BindSamplersGlow(first uint, samplers []uint32).

For example
https://github.com/errcw/glow/blob/master/xml/spec/egl.xml#L179
gives
DEFAULT_DISPLAY = ((EGLNativeDisplayType)0)
needs to be rewritten to
DEFAULT_DISPLAY = C.EGLNativeDisplayType(0)

UPDATE:
needs more work
./package.go:120: cannot convert 0 (type int) to type C.EGLNativeDisplayType

Not really an issue, just another idea dump.
I have found this debug binding to be very useful, you guys may want to implement something similar.

https://github.com/bryanturley/gl/blob/master/dbg/gl.go#L31

It doesn't do any asm/cgo directly it calls the first binding so that it can be mixed with things that don't use it.
That was a first attempt, I need to make changes lower to make it generate better debug information.
Took me about 30minutes to add it, all the heavy lifting is already done since you are generating funcs already.
This style of debug package could replace the need for things like
https://code.google.com/p/glintercept/

One of my lasting concerns is the side of the wrappers generated by Glow. For instance Azul3D has an OpenGL 2 renderer (http://github.com/azul3d/gfx-gl2) that uses a somewhat small subset of the OpenGL 2.0 API.

Since most of the symbols (enums and functions) generated by Glow are not actually used by us -- it seems silly to compile them at all. I'd like to be able to specify a JSON input file to Glow that would specify the symbols that we actually want, for example:

{
    "Enums": [
        "GL_CCW",
        "GL_COLOR_ATTACHMENT0",
        "GL_COMPRESSED_RGB"
    ],
    "Functions": [
        "glBindTextures",
        "glBindVertexArray"
    ]
}

And Glow could generate just those symbols, greatly reducing the compilation time. Although I think it's not strictly the same tactic -- this could also help others trying to deal with issue #23

From reading https://github.com/errcw/glow#custom-packages (and the fact that chsc/gogl supports it), it sounds like it should work. But I wanted to ask before attempting it.

The struct _cl_event and struct _cl_context types hit the fall-through case when finding a Go type to match the C type and the resulting Go code is invalid.

For more details see:

https://github.com/slimsag/cgo-batching
and
azul3d-legacy/issues#17