I 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
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. =)
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.
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).
> 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'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.
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.
```
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.
```
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. '^^
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.
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.
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.
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