TinyGL: A Small, Free and Fast Subset of OpenGL
bellard.org
bellard.org
Key differences to TinyGL: Mesa llvmpipe implements "all" of OpenGL and GLES2 (That is, everything that is implemented in Mesa works with this backend) and the rendering is accurate.
I have not done a head-to-head benchmark, and I don't think it would be that interesting since the two libraries are from entirely different ages.
The existence of llvmpipe was part of the rationale for Qt5 to require OpenGL (GLES?) for rendering [1]. Qt5 has no other rendering backend.
[1]: I remember this from the beginning of Qt5 development, which is so long ago that I have a hard time finding a quotation. Maybe I can use this Phoronix article as backup: http://www.phoronix.com/scan.php?page=news_item&px=MTA5ODc "The Qt developers praised the CPU-based Gallium3D driver and will be relying upon LLVMpipe when no GPU hardware driver is available. They say that using LLVMpipe is working better than any software rasterizer of their own. " "LLVMpipe remains too slow for OpenGL gaming (...), but it's good enough for a tool-kit and composited desktop."
It is used, for example, by ResidualVM[0], the ScummVM sister project dedicated to 3D games, like Grim Fandango.
These games were rendered in software in the 90's, the lack of hardware acceleration is not an issue. When they started Residual, it was AFAIK the only portable 3D renderer.
Using the OpenGL API also meant that they could easily switch to an hardware accelerated backend if needed.
When Direct3D 10/11 came out, it was considered as a lot better to prgram for than the corresponding OpenGL versions. See for example the following article from 2011
> http://www.bit-tech.net/news/gaming/2011/03/11/carmack-direc...
where John Carmack clearly says that he now prefers Direct3D over OpenGL.
reference: http://vr-zone.com/articles/john-carmack-mantle-became-inter...
> http://www.extremetech.com/gaming/177407-microsoft-hints-tha...
On the other hand: Even if the overhead for OpenGL can be lowered a lot (and I believe this is possible), this will be released as extension set - not as an elegant revised API as new DirectX versions do (see the Longs Peak fiasco).
It's not "will be released", it's in current drivers - some in extensions, some in core Opengl 4.4 or earlier. As far as OpenGL backwards compatible approach, I think that's pretty much a necessity as long when you consider the stakeholders.
D3D and OpenGL are pretty similar from 10000 ft. Really the GPU vendors should just open up instruction sets, binary formats and ABIs for their devices, and focus on writing high quality open source compiler backends for them, and let people program GPUs whichever way they want.
Since almost any embedded chip will have some graphics cores, or in their absence I have no idea what you are trying to render for, a software only API is insane in this day and age. The performance differentials are so many orders of magnitude between the best CPU and the worst GPU it isn't fair.
Software rendering died a decade ago, and should be left dead. We have great new tech like EGL and GLES growth to standardize on a base set of accelerated 3d functionality you can just assume. Which is great.
Plus, there's always the people who like the challenge of creating something with mesa in dosbox for the fun of it.
If you are running Mesa you can try it by setting LIBGL_ALWAYS_SOFTWARE=1.
You gan try a quick demo on either your GPU or their software renderer with OpenGL Extension Viewer[0].
[0]: https://itunes.apple.com/us/app/opengl-extensions-viewer/id4...
Now even the cheapest and lousiest PC hardware is orders of magnitude faster than back then. Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough?
The benefit is that it is more reliable. If you can shove pixels on to the screen, you can do graphics in software. The graphics stack for hardware accelerated 3D graphics is incredibly complex and buggy. Questions like if I buy this laptop, will my graphics work? are sad sad reality. Problems like libGL error: failed to load driver: i915 are reality. And for those who write graphics code, doing workarounds for specific chipsets or drivers is reality.
Because games in the 90s used < 1k poly models for characters, I don't think you could get away with those nowdays, not even on mobile.
The people working on that, Abrash and Sartain, went on to Intel to do Larrabee - something akin to "software renderer on GPU". If that had worked out, maybe we wouldn't be in the current dark ages, where GPUs are a nightmare to program and everybody suffers from the buggy, closed proprietary software stacks that hide the hardware behind many layers of obfuscation.
There is a reason than every console since the PS1 has a rendering coprocessor. And why all your phones have them, and why every CPU vendor is shipping APUs now.
Yea, you could make a significantly better looking software rendered quake today with 10x the triangles and texture resolution. But that game would still run 1000x faster on a GPU priced the same as the cpu doing the software rendering.
"Software rendering died a decade ago, and should be left dead."
I don't think entertainment industry CGI folks agree with you, at least not yet :)
Servers that need to render Web pages offline, for example for automated testing, may benefit from something like this. Or you may be working in an environment where you can't assume the GPU driver even works without crashing (sadly, this scenario describes Web browsers). In these cases, while you don't want to render with software, you need a software fallback because users won't accept not being able to run the browser engine at all.