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.
```
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.
```
lunixbochs|3 years ago
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
nominatronic|3 years ago
VikingCoder|3 years ago
djmips|3 years ago
https://en.wikipedia.org/wiki/MiniGL
calin2k|3 years ago
mpweiher|3 years ago
Not 100% sure whether that speaks for or against the hypothesis of abandonware. Formally clearly against ;-)
unknown|3 years ago
[deleted]
sylware|3 years ago
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).
genpfault|3 years ago
> 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.
[1]: https://docs.mesa3d.org/drivers/llvmpipe.html
warkanlock|3 years ago
aap_|3 years ago
SpaghettiCthulu|3 years ago
zevv|3 years ago
akomtu|3 years ago
dusted|3 years ago
yakorevivan|3 years ago
unknown|3 years ago
[deleted]
macshome|3 years ago
Brajeshwar|3 years ago
- 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. ```
melling|3 years ago
- changed license to MIT
- fixed compilation errors
- fixed lighting bug
- fixed color conversions
https://bellard.org/TinyGL/changelog.html
FpUser|3 years ago
pipeline_peak|3 years ago
unknown|3 years ago
[deleted]