I spend a few minutes looking at the code this morning. This is on OSX, an m2 machine, so CGO_ENABLED=0 GOOS=plan9 GOARCH=amd64 go build Adding a few build tags for !plan9 gets me to the real errors.
I mainly got interested this because it seems to have broad portability, and I believe not all these run opengl? * [Windows](https://ebitengine.org/en/documents/install.html?os=windows) (No Cgo required!) * [macOS](https://ebitengine.org/en/documents/install.html?os=darwin) * [Linux](https://ebitengine.org/en/documents/install.html?os=linux) * [FreeBSD](https://ebitengine.org/en/documents/install.html?os=freebsd) * [Android](https://ebitengine.org/en/documents/mobile.html) * [iOS](https://ebitengine.org/en/documents/mobile.html) * [WebAssembly](https://ebitengine.org/en/documents/webassembly.html) * Nintendo Switch * Xbox (Xbox support is limited and not available to everyone. Negotiations are currently underway to make it accessible to all.) Here's the API: https://pkg.go.dev/github.com/hajimehoshi/ebiten/v2#pkg-functions not that complicated compared to some of these libraries. I would not stress too much about implementing GPUs on Plan 9. From what I can see, it's not a requirement for ebiten, it's just something ebiten can use. On OSX: cd examples/cursor CGO_ENABLED=0 go build ofiles shows: ./cursor: /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 726.2.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4109.1.255) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61901.40.77) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2685.20.119) /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1965.1.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4109.1.255) I have no idea if opengl is any part of these libraries, someone else might. On Sun, Nov 30, 2025 at 7:13 AM <[email protected]> wrote: > On Sat, Nov 29, 2025 at 06:27:08PM -0500, [email protected] wrote: > > Quoth Noam Preil <[email protected]>: > > > > > > I'm going to respectfully disagree without having ever done any non > trivial graphics work: there's multiple examples of drivers that were done > by a small group independently over a long period of time. > > > > > > See e.g. asahi working against a hostile vendor. > > > > They're also building on a huge amount of work, often > > commercially sponsored, around the whole linux graphics > > stack. > > > > It's possible to get there, but given that we've got a > > fraction of the people hacking on things... it'll take > > years of incremental work and some real simplifications > > to the design. > > FWIW, I concur. On NetBSD, things started to go weird after they had > imported linux kernel related GPU support, the alien code weighting... > 50%! of the previous existing code (kernel for all flavors + userland). > And once imported, it was already obsolete because it is a fast moving > target. And it is hugely memory related, and memory is at the core of an > OS, so importing an alien code with an alien memory interface was > doomed. > > After fighting to find a way (starting at the KMS or DRM end; then > reverting to the user interface to try to reach the kernel articulation), > I personnally concluded that whether one has to stick to Linux for this > (not try to follow; it is hopeless), or find a totally different way to > do things (I mean the interface between the kernel and the GPUs; what > are the GPUs today can not be changed). And, IMHO, the design has > to start thinking about the kernel---after having found a thread > to what should be done, look at what is existing to sort the pieces > and implement the missing glue. > > But, on the other hand, when it comes to 2D, it used to work without > much ado and with not full modern GPUs but in fact VGA (meaning Video > Graphics Array): an image, a clock to master when to send an image to > a display, and a circuitry to feed at the proper time these images to > a display (in fact, there were at some time "vectorial" displays, that > didn't take raster data but vectorial instructions: the > plotters, that took a pen and drew lines; since they were sequential, > they were not limited in the size and complexity of what had to be > drawn---I personnally loved watching the execution, step by step, of the > graphical program). > > This is also why, in the mean time, I want to focus on rasterizing > capabilities (taken from METAFONT) and to see how far (and with what > efficiency) one can draw 2D images, including glyphes, with CPU like > cores---and I want to get rid of a PostScript interpreter and even > of other graphics libraries. So if I want to use Plan9 for programming, > TeX writing and rendering or even rendering GIS data (KerGIS), I will > depend on strictly nothing. I'm not doing 3D realtime motion stuff; > neither cryptocurrency mining nor A.I., so... > > As usual (but as a French, it is a habit), I'm not trying to obtain > something claimed mandatory, I'm trying to do without. > -- > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M05c08b35ab56409ae6502d45 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
