Native opengl support

[cch...@gmail.com]

I am curious as to what it would take to add native opengl support to go, avoiding the overhead of cgo.

Specifically, what code needs to be changed that is preventing native opengl support? And where does this code lie in the spectrum from drivers to my go binary.

[V0idExp]

I'm also interested in having opengl native supported. 

[André Moraes]

On Fri, Jun 1, 2012 at 4:59 AM, V0idExp <voi...@gmail.com> wrote:
> I'm also interested in having opengl native supported.

Lot's of syscalls? :)

I don't know how many native OpenGL implementations exists out there,
I just can think of bindings for the C api.



--
André Moraes
http://amoraes.info

[bryanturley]

I think to get anymore more native you would have to write the client side libraries in go, and then keep them in sync with the moving target that is the drivers.
Best way to lessen your cgo overhead would be to not use immediate mode rendering (if you are).
Read up on buffer objects, vertex arrays, etc...

On Thursday, May 31, 2012 5:51:02 PM UTC-5, cch...@gmail.com wrote:

I am curious as to what it would take to add native opengl support to go, avoiding the overhead of cgo.

Specifically, what code needs to be changed that is preventing native opengl support? And where does this code lie in the spectrum from drivers to my go binary.

[cch...@gmail.com]

Define client side libraries. What is the current "client side library" that is not in go?

[Mikael Gustavsson]

The way OpenGL is defined, an application uses a OpenGL client library which implements the OpenGL API to talk to a OpenGL server which does the rendering of your commands. However, the interface between the "client" and "server" part of OpenGL is not specified, and unless you are using an unusual setup where your OpenGL commands are being sent over the network to be rendered on a separate computer, the graphics card driver can be seen as implementing both the client and server parts in one blob.

 

OpenGL is a C standard, all OpenGL implementations only have C interfaces.

If you somehow want to be more low level than talking to those via CGO, you have to implement you own OpenGL-like graphics driver in Go.

Sounds like an interesting project :)

[Paulo Pinto]

Unless you're writing an operating system in Go, you will always need
to get down
to C at some level, as it is the current API in most operating systems
(some use C++ as well).

On 2 Jun., 03:26, cche...@gmail.com wrote:
> Does this mean that to avoid cgo a Go graphics driver would need to be
> implemented for each graphics card out there?

[Albert Strasheim]

Hello

On Friday, June 1, 2012 12:51:02 AM UTC+2, cch...@gmail.com wrote:

I am curious as to what it would take to add native opengl support to go, avoiding the overhead of cgo.

Specifically, what code needs to be changed that is preventing native opengl support? And where does this code lie in the spectrum from drivers to my go binary.

It might be worth it to channel your energy into quantifying and fixing the cgo overheads (which benefits everyone that has to call a C library), instead of trying to do something just for OpenGL.

Also, I don't think cgo for gccgo is quite there yet, but depending on your target platform, there might be some help down that avenue in the future.

Regards

Albert