4 ms·

I'm curious. The page was last updated March 2002. Is this project still active? Is this even still relevant given OpenGL ES?

zanny 12y ago
This is a software mode graphics API for embedded. 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.
- cordite 12y ago
  Software rendering can be good for making references to compare to--at least for driver implementors. Plus, there's always the people who like the challenge of creating something with mesa in dosbox for the fun of it.
- Kliment 12y ago
  Software rendering is alive and well on headless setups with no GPU.
- fulafel 12y ago
  Not dead, check out llvmpipe in Mesa. Ubuntu's Unity desktop uses it by default in lieu of accelerated GL. Phoronix benchmarks it regularly, getting 20 fps in some games. If you are running Mesa you can try it by setting LIBGL_ALWAYS_SOFTWARE=1.
  - lloeki 12y ago
    Also, Apple has one notably used as a fallback to display Core Animation stuff on a VESA driver (for safe mode, VMs, multiseat remote sessions via VNC). It goes up to OpenGL 4.1 and is fast enough to have the OS X UI be quite usable. 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/id444052073?mt=12 https://itunes.apple.com/us/app/opengl-extensions-viewer/id4...
- clarry 12y ago
  Software rendering was fast enough for games in the 90s. On machines featuring a few megabytes of RAM and CPU clock speeds measured in tens of, or at most a couple hundred MHz. 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.
  - moonchrome 12y ago
    >Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough? 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.
    - fulafel 12y ago
      Unreal Tournament 2004 had a software renderer with good performance, on the single core CPUs of the era. See http://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765 http://www.drdobbs.com/architecture-and-design/optimizing-pi... 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.
  - zanny 12y ago
    It wasn't that software rendering was "fast enough", it was that we didn't have hardware acceleration, so game developers had to use what they could get away with. 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.
- fsloth 12y ago
  To use the age old tradition of out of context quotes: "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 :)
- pcwalton 12y ago
  > 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. 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.
  - zanny 12y ago
    If your server is using a software renderer like llvmpipe because you don't want to install some offloading GPU hardware, you are losing money - you will rapidly pay more in electricity on wasted core cycles and scaling issues because of huge load doing 100x slower software rendering than buying budget GPUs to do the work.
    - wolfgke 12y ago
      On the other hand most commercial GPU drivers can be considered to be full of security-related bugs. Would you really trust your servers with them?
asb 12y ago
It's used in residual-vm (the scummvm sister project for grim Fandango, monkey island 4 etc). I believe they have a local fork.

zanny 12y ago

This is a software mode graphics API for embedded. 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.

cordite 12y ago
Software rendering can be good for making references to compare to--at least for driver implementors. Plus, there's always the people who like the challenge of creating something with mesa in dosbox for the fun of it.
Kliment 12y ago
Software rendering is alive and well on headless setups with no GPU.
fulafel 12y ago
Not dead, check out llvmpipe in Mesa. Ubuntu's Unity desktop uses it by default in lieu of accelerated GL. Phoronix benchmarks it regularly, getting 20 fps in some games. If you are running Mesa you can try it by setting LIBGL_ALWAYS_SOFTWARE=1.
- lloeki 12y ago
  Also, Apple has one notably used as a fallback to display Core Animation stuff on a VESA driver (for safe mode, VMs, multiseat remote sessions via VNC). It goes up to OpenGL 4.1 and is fast enough to have the OS X UI be quite usable. 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/id444052073?mt=12 https://itunes.apple.com/us/app/opengl-extensions-viewer/id4...
clarry 12y ago
Software rendering was fast enough for games in the 90s. On machines featuring a few megabytes of RAM and CPU clock speeds measured in tens of, or at most a couple hundred MHz. 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.
- moonchrome 12y ago
  >Why wouldn't software rendering be fast enough now that it is orders of magnitude faster than when it was fast enough? 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.
  - fulafel 12y ago
    Unreal Tournament 2004 had a software renderer with good performance, on the single core CPUs of the era. See http://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765 http://www.drdobbs.com/architecture-and-design/optimizing-pi... 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.
- zanny 12y ago
  It wasn't that software rendering was "fast enough", it was that we didn't have hardware acceleration, so game developers had to use what they could get away with. 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.
fsloth 12y ago
To use the age old tradition of out of context quotes: "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 :)
pcwalton 12y ago
> 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. 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.
- zanny 12y ago
  If your server is using a software renderer like llvmpipe because you don't want to install some offloading GPU hardware, you are losing money - you will rapidly pay more in electricity on wasted core cycles and scaling issues because of huge load doing 100x slower software rendering than buying budget GPUs to do the work.
  - wolfgke 12y ago
    On the other hand most commercial GPU drivers can be considered to be full of security-related bugs. Would you really trust your servers with them?

asb 12y ago

It's used in residual-vm (the scummvm sister project for grim Fandango, monkey island 4 etc). I believe they have a local fork.