TinyGL 0.4.1
bellard.orgI used to work on a project called glshim (which ptitseb still maintains as gl4es, used by box86). glshim implements an ABI-compatible OpenGL 1.x fixed function API (as libGL.so.1) on top of an OpenGL ES 1.x driver. This allows you to accelerate completely unmodified OpenGL programs on mobile Linux devices such as the OpenPandora.
This approach even works with x86 user-mode emulation, by serializing render commands into a shared memory ring buffer and running the driver in native code out-of-process (which as a bonus was also generally faster than rendering in-process).
I built glshim after hand porting a bunch of open-source Linux games from OpenGL to OpenGL ES. The last game I hand-ported like this was Introversion's Uplink Hacker Elite. The diff was thousands of lines, and the resulting port had buggy rendering and blurry fonts, so I got fed up with hand ports and started working on a universal solution.
After a few years, I had ironed out most of the bugs in glshim, and ports to the Pandora were much easier. Uplink, however, was still in a sorry state. It made heavy use of glBitmap for crisp font rendering, and glBitmap was very slow to emulate on top of OpenGL ES 1.x. glBitmap basically manipulates framebuffer pixels directly, and the easiest way I found to do that was to upload a texture and render it with GL_NEAREST. Texture uploads seemed to be extremely slow and CPU-bound on the Pandora's Cortex A8 / PowerVR SGX 530. I ended up batching subsequent glBitmap calls, trying to coalesce them into a single texture upload per frame, and with that I still only managed single-digit fps.
With glshim, I had a moderately complete OpenGL implementation that only relied on a small subset of the OpenGL ES API. Then I stumbled on TinyGL. I realized that despite TinyGL not implementing much of the full OpenGL API, it was very fast and implemented basically everything I needed from OpenGL ES for glshim to work. So I forked it as "TinyGLES", deleted the extra GL parts, and optimized the rendering paths for ARM NEON. It ended up making a really good software rendering backend for glshim. I used this to finally release a good version of Uplink for the Pandora, which ran at around 80fps! With TinyGLES, glBitmap could blit directly to the software framebuffer, avoiding the slow/buggy texture emulation path.
It had been a few years and I couldn't find the modified source for my Uplink port, so I just swapped out the libGL.so file when I updated Uplink to use TinyGLES. But some users found an annoying bug in the port. Anytime you restarted the game, it put you directly in the "new game" menu, instead of allowing you to pick between new game or loading a save. I ended up fixing this with a binary patch to the game executable (which forced the game to the main menu screen on every launch), and that's the version currently available for the Pandora: http://repo.openpandora.org/?page=detail&app=uplink
Jamie Zawinski wrote a similar shim layer to port xscreensaver from OpenGL to OpenGL ES, and had quite a rant about it: https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-...
PSA: jwz.org redirects to a unique image when linked from HN unless you are blocking the HTTP Referer header.
This can also be avoided by copying & pasting the url into a new tab.
Indeed (:
This link might work better for HN users: https://web.archive.org/web/20221122141924/https://www.jwz.o...
I ended up writing my own software "kind of OpenGL" implementation at one point. The main reason why was because I was trying to take photos of objects, and triangles that we thought mapped to their surfaces, and I was trying to map the pixels in the photos back onto the textures of those triangles. I had a heck of a time with interpolating texture coordinates, until I learned more about the homogenous coordinate and how you have to interpolate then divide, etc. Having an existing simple software implementation (like this one) would have helped a bunch. =)
Anyone remember the various MiniGL that were initially implemented to run Quake?
I like what he does, but projects tend to loose interest from the author and become abandonware. For one project he accepted to publish it on github and forks continued to develop it, but original project stagnated.
The last release, 0.4 was released March '02. This release March of this year, so almost exactly 20 years later.
Not 100% sure whether that speaks for or against the hypothesis of abandonware. Formally clearly against ;-)
mmmh... maybe it could be a good replacement of a hardware accelerated 32bits libGL which is still and currently required by the steam client (but it seems they are moving finally the last bits of 32bits code to libcef, but it is valve then don't be impatient). oh, yeah and I play games on elf/linux without that msft grade horrible proton (= wine with plentyfull of components copied straight from doz, as far as I know... that said a lean wine build for core win64 and vkd3d for vulkan/dx12 support... mmmh... wonder which games could run with that).
I wrote my own, but I had to put in assembly code to make it fast enough (amd zen2) so I am pessimistic about tinyGL being fast enough for that, and it is really a quick and dirty thing with bugs to avoid to build that horrible libGL for 32bits ONLY for the steam client (all the games I play are native vulkan3D, but I still run x11 native so I don't know about their wayland support).
Check out Mesa's llvmpipe[1]:
> The Gallium LLVMpipe driver is a software rasterizer that uses LLVM to do runtime code generation. Shaders, point/line/triangle rasterization and vertex processing are implemented with LLVM IR which is translated to x86, x86-64, or ppc64le machine code. Also, the driver is multithreaded to take advantage of multiple CPU cores (up to 32 at this time). It’s the fastest software rasterizer for Mesa.
It is c++, then it is a definitive no-no. That's why I wrote my own in plain and simple C.
I've always felt that OpenGL was too abstract for graphics novices; perhaps this tiny subset of GL will change that.
It's not particularly abstract if you consider the hardware it was originally designed for. But GPUs have changed since then and all the modern features feel a bit awkward.
Would you say modern alternatives are any better? (looking at you, Vulcan)
I spent one weekend going through the official Khronos tutorial for Vulcan, and wrote (understood, then typed -- as opposed to copy+pasted) the bare minimum necessary to get a triangle on the screen: it came to 900+ lines of code.
Vulcan is not at all like an "enhanced OpenGL" -- it's for experts to leverage while designing the next generation of high-performance graphics libraries.
Triangle-on-screen using OpenGL is on the order of ~100 lines:
https://github.com/genpfault/glfw-mcve-base/blob/master/src/...
Fabrice Bellard is a robot from outer space - this must be the only explanation.
Maybe he is the collective consciousness of the mycelium network.
Yes, Massive Talent is a good description.
Seriously man... I wonder the same... How can one person create so many brilliant softwares
Being one person makes it easier not harder. The meetings are quicker for one thing.
Taking 20 years to move from 0.4 to 0.4.1 seems like a long long time.
Well, I'm surprised he has the time/intention to do that in between for us mere mortals. Here are a few references;
- https://en.wikipedia.org/wiki/Bellard%27s_formula
- https://en.wikipedia.org/wiki/Fabrice_Bellard
``` In April 2021 his Artificial Neural Network based data compressor, NNCP, took first place out of hundreds in the Large Text Compression Benchmark. To write the compressor, Bellard wrote his own Artificial Neural Network library, LibNC ("C Library for Tensor Manipulation"), publicly available. ```
One glance upon the majesty of Bellard's works is enough to give even a 10x SWE imposter syndrome.
Not only that, but he's a heck of a nice guy. Back in 2003 I discovered qemu (I was using Bochs at the time) and it was a huge boost for my work building emulated environments. My colleague sent an email to Fabrice Bellard to thank him for his work, and he replied very nicely that he was happy that his software was actually useful to others.
Since I teach a fair amount of machine learning, I have been pondering on what a “minimal”, low-level implementation of a library would look like and got very excited hearing about LibNC. Sadly it seems like Bellard is keeping the source for this one: “The LibNC library is free to use as a binary shared library. Contact the author if access to its source code is required.” [1]. Not that you can every accuse the man of being greedy after all the code he has shared, but dang I wanted to read it. '^^
Seems that it would be worth your time to contact Bellard and ask about making it available for teaching (and/or under an open license of some kind)?
Thank you, I will try to gather the courage. Partially I guess I suspect that he chose to do what he did for a (good?) reason and I do not really think it is my place to question it. Partially I guess I am somewhat reluctant to poke a borderline god of our discipline with a beggar’s request. '^^
No promises, but I will try to gather the courage and thank you for the encouragement.
TinyGrad is basically that and is open source, albeit not in C
Yes, kind of, but it depends on NumPy which is fairly big if your goal is for students to grasp and demystify the whole way down to the hardware. Other candidates would be torch7 [1], but it is somewhat married to the Lua API which drives it.
You might like micrograd: https://github.com/karpathy/micrograd. There's also this video where the author explains how he built it: https://www.youtube.com/watch?v=VMj-3S1tku0
Not actively developed. Only a few small changes:
- changed license to MIT
- fixed compilation errors
- fixed lighting bug
- fixed color conversions
You might want to look at Fabrice Bellard's page and see what he has accomplished. He is a giant.
Thanks, now I realize how exceptional QuickJS is, a ES6 compatible JS runtime and maintained by a single person. We are bundling it into our web app to run sandboxed code.
Until you look at everything in between that Bellard has done