New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove dependency on cgo #109

Open
silbinarywolf opened this Issue Sep 23, 2018 · 21 comments

Comments

Projects
None yet
5 participants
@silbinarywolf

silbinarywolf commented Sep 23, 2018

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

This comment has been minimized.

Member

dmitshur commented Sep 23, 2018

how feasible is this?

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

@Noofbiz

This comment has been minimized.

Noofbiz commented Sep 23, 2018

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

This comment has been minimized.

silbinarywolf commented Sep 24, 2018

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

This comment has been minimized.

silbinarywolf commented Sep 30, 2018

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

@jeff-emanuel

This comment has been minimized.

jeff-emanuel commented Sep 30, 2018

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 1, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Oct 1, 2018

DllImport

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

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 4, 2018

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

@silbinarywolf

This comment has been minimized.

silbinarywolf commented Oct 5, 2018

@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

This comment has been minimized.

Member

hajimehoshi commented Oct 14, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Oct 20, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Oct 20, 2018

glfw/glfw#120 I got it, opengl32 is not enough.

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 21, 2018

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

This comment has been minimized.

Member

dmitshur commented Oct 21, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Oct 21, 2018

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

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 26, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Oct 27, 2018

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

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 27, 2018

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

This comment has been minimized.

Member

hajimehoshi commented Nov 9, 2018

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

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Nov 12, 2018

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

@dmitshur

This comment has been minimized.

Member

dmitshur commented Nov 12, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment