search

go-gl / gl

Go bindings for OpenGL (generated via glow)
MIT License
1.05k stars 72 forks source link

remove dependency on cgo #109

Open silbinarywolf opened 5 years ago

silbinarywolf commented 5 years ago

How much effort is this or how feasible is this? It'd be great if I didn't need to install additional build tools on my Windows machines when working with this library. It would also make cross-compilation from Windows to Linux easier.

I'd be willing to put in the work if someone is able to point to examples of other repositories that removed the dependency on cgo.

dmitshur commented 5 years ago

how feasible is this?

I don't know of a way of doing this. If someone knows a way, please share.

Noofbiz commented 5 years ago

I honestly don't think this would be possible. OpenGL itself is an API for graphics and the interface is all written in C, so you don't have to know (proprietary) things about the graphics card and driver. Even if you did reverse engineer your own card and figure out what memory addresses and what needs to be written there to perform what, it would work specifically for your card and driver. You'd have to do it all over again for every graphics card / driver setup out there. That's exactly the problem OpenGL was created to solve. Another issue would be whether or not Go could actually do this since it's got a GC. It would require a lot of working around that to get it functional.

silbinarywolf commented 5 years ago

I'd imagine a solution like c2goasm, where we have a tool to auto-generate Go assembly versions of each of the OpenGL functions.

c2goasm: https://github.com/minio/c2goasm Article: https://blog.minio.io/c2goasm-c-to-go-assembly-bb723d2f777f

silbinarywolf commented 5 years ago

Another potential solution is using this too: https://github.com/elliotchance/c2go

jeff-emanuel commented 5 years ago

That's not relevant. You need Go code to call a C API. You can't convert the opengl implementation to Go. (I guess technically you could, but you'd then have a dog slow software implementation. )

On Sun, Sep 30, 2018, 2:19 AM Jake Bentvelzen notifications@github.com wrote:

Another potential solution is using this too: https://github.com/elliotchance/c2go

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/go-gl/gl/issues/109#issuecomment-425703634, or mute the thread https://github.com/notifications/unsubscribe-auth/AhhKJwvW76gqHgMSBC8uikgGIckgSFNJks5ugH51gaJpZM4W1mHp .

hajimehoshi commented 5 years ago

This is possible at least on Windows by DllImport, and this should be worth trying since it is hard to install gcc in Windows compared to other Posix OSes like macOS or Linux.

hajimehoshi commented 5 years ago

DllImport

I meant NewLazyDLL. For example, I could call WinMM functions without cgo: https://github.com/hajimehoshi/oto/blob/master/winmm_windows.go

hajimehoshi commented 5 years ago

@silbinarywolf I was wondering if you are working on this. If not, can I do this (for Windows)?

silbinarywolf commented 5 years ago

@hajimehoshi I haven't started anything and I've only toyed with a few of the c2go libraries to see how they work. So go ahead and do this :)

hajimehoshi commented 5 years ago

I realized this is important to improve even go get time: Now it takes very long time to go get -u github.com/go-gl/gl on Windows.

hajimehoshi commented 5 years ago

Question: now on Windows, wglGetProcAddress is used when available. Would it be fine to always use LazyDLL("opengl32") and its NewProc? Will they cause different results?

hajimehoshi commented 5 years ago

https://github.com/glfw/glfw/issues/120 I got it, opengl32 is not enough.

hajimehoshi commented 5 years ago

https://godoc.org/github.com/go-gl/gl/v2.1/gl#BufferStorageExternalEXT

Oops, there are APIs that exposes C types. This means that we'll break backward compatibility if we eliminate dependencies on Cgo :-/

dmitshur commented 5 years ago

Indeed. However, there's only 8 of them (compared to hundreds or thousands of Go types), and I don't think they should've been exposed in the first place. I don't know whether they're functional (it might not be possible to use them).

According to https://golang.org/cmd/cgo/, "a Go package should not expose C types in its exported API":

Cgo translates C types into equivalent unexported Go types. Because the translations are unexported, a Go package should not expose C types in its exported API: a C type used in one Go package is different from the same C type used in another.

hajimehoshi commented 5 years ago

I confirmed these functions are not used (at least on GitHub). I'm now writing proposal to replace these types :-)

hajimehoshi commented 5 years ago

I think I've done 80%: https://github.com/hajimehoshi/glow/tree/nocgo

Probably I'll be able to send a PR this week end :-)

hajimehoshi commented 5 years ago

The current problem is that func LGPUCopyImageSubDataNVX has so many arguments that syscall.SyscallN cannot accept :-/

hajimehoshi commented 5 years ago

Hi,

I wrote the proposal https://docs.google.com/document/d/1mqquznil9fR2amtb3eTC2ObCx3A8Af_5INqKjO-pKDg/edit?usp=sharing how to eliminate Cgo usages on Windows. Feedbacks are welcome!

Before starting to review the PR, I'd like to confirm that we agree the direction. Thanks!

hajimehoshi commented 5 years ago

Hi, what's going on this? (@dmitshur ?)

hajimehoshi commented 5 years ago

That is unfortunate, but if we couldn't reach agreement, I'd need to make a fork of go-gl...

dmitshur commented 5 years ago

I think we did reach agreement. We talked on slack and I left some comments on the proposal document. As long as you're willing to help maintain the Windows cgo-free version, we're happy to accept it.

neclepsio commented 4 years ago

In the meantime it gets merged, you can use my fork.

MatejMagat305 commented 2 years ago

@neclepsio

In the meantime it gets merged, you can use my fork. it work perfeckly

Can I ask, when will it official?

Edouard127 commented 1 year ago

This absolutely needs to be merged, I literally can't build anything on Windows and this fixed my issue

In the meantime it gets merged, you can use my fork.

MatejMagat305 commented 4 months ago

Friedly ping

MatejMagat305 commented 4 months ago

In the meantime it gets merged, you can use my fork.

Wait, wasn`t it pull request? If the problem is not pull request, I will look to this ... or is it need fix also glfw?

Seb-C commented 3 months ago

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo

All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

MatejMagat305 commented 3 months ago

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo

All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

fastcgo is unsafe and use cgo, this is thread obout remove them similar https://github.com/ebitengine/purego

Seb-C commented 3 months ago

Has anyone made an attempt using this? https://github.com/petermattis/fastcgo All of my calls to OpenGL are inside an OS-locked thread, so my understanding is that the drawbacks would not be an issue.

fastcgo is unsafe and use cgo, this is thread obout remove them similar https://github.com/ebitengine/purego

Oh, you are correct, sorry about this. I confused this thread for a discussion about the performance overhead of cgo, while this one is more about the build process.