37 lines
5.5 KiB
Markdown
37 lines
5.5 KiB
Markdown
# Software Rendering
|
|
|
|
Sofware (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the help of [graphics card](gpu.md) (GPU), i.e. computing images only with [CPU](cpu.md). This mostly means rendering [3D](3d.md) graphics but can also refer to other kinds of graphics such as drawing [fonts](font.md) or [video](video.md). Before GPUs were invented, all rendering was done in software, of course -- games such as [Quake](quake.md) were designed with SW rendering and only added possible GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md).
|
|
|
|
SW rendering has advantages and disadvantages. Firstly it is **much slower** -- GPUs are designed to perform graphics-specific operations very quickly and, more importantly, they can process many pixels (and other elements) in [parallel](parallelism.md), while a CPU has to compute pixels sequentially one by one and that in addition to all other computations it is otherwise performing. This causes a much lower [FPS](fps.md) in SW rendering. For this reasons SW rendering is also normally of **lower quality** (lower resolution, [nearest neighbour](nn.md) texture filtering, ...) to allow at least somewhat workable FPS.
|
|
|
|
On the other hand SW rendering is more [portable](portability.md) (as it can be written in a portable language such as [C](c.md)), less [bloated](bloat.md) and **eliminates the [dependency](dependency.md) on GPU** so it will be supported almost anywhere as every computer has a CPU, while not all computers (such as [embedded](embedded.md) devices) have a GPU (or, if they have it, it may not be sufficient, supported or have a required [driver](driver.md)). SW rendering may also be implemented in a simpler way and it may be easier to deal with as there is e.g. no need to write [shaders](shader.md) in a special language, manage transfer of data between CPU and GPU or deal with parallel programming. It is the [KISS](kiss.md) approach.
|
|
|
|
SW rendering may also utilize a much wider variety of rendering techniques than only 3D [rasterization](rasterization.md) traditionally used with [GPUs](gpu.md) and their [APIs](api.md), thanks to not being limited by hard-wired pipelines. This may include [splatting](splatting.md), [raytracing](raytracing.md) or [BSP rendering](bsp.md) (and many other ["pseudo 3D"](pseudo3d.md) techniques).
|
|
|
|
A lot of software and rendering frameworks offer both options: accelerated rendering using GPU and SW rendering as a [fallback](fallback.md) (in case the first option is not possible). Sometimes there exists a rendering [API](api.md) that has both an accelerated and software implementation (e.g. [TinyGL](tinygl.md) for [OpenGL](opengl.md)).
|
|
|
|
For simpler and even somewhat more complex graphics **purely software rendering is a lot of times the best choice**. [LRS](lrs.md) suggests you prefer this kind of rendering for its simplicity and portability, at least as one possible option. On devices with lower resolution not many pixels need to be computed so SW rendering can actually be pretty fast despite low specs, and on "big" computers there is nowadays usually an extremely fast CPU available that can handle comfortable FPS at higher resolutions. There is a LRS software renderer you can use: [small3dlib](s3l.md).
|
|
|
|
SW renderers are also written for the purpose of verifying rendering hardware, i.e. as a [reference implementation](reference_implementation.md).
|
|
|
|
Note that SW rendering doesn't mean our program is never touching [GPU](gpu.md) at all, in fact most personal computers nowadays **require** some kind of GPU to even display anything. SW rendering only means that computation of the image to be displayed doesn't use any hardware specialized for this purpose.
|
|
|
|
Some SW renderers make use of specialized CPU instructions such as [MMX](mmx.md) which can make SW rendering faster thanks to handling multiple data in a single step. This is kind of a mid way: it is not using a GPU per se but only a mild form of hardware acceleration. The speed won't reach that of a GPU but will outperform a "pure" SW renderer. However the disadvantage of a hardware dependency is still present: the CPU has to support the MMX instruction set. Good renderers only use these instructions optionally and fall back to general implementation in case MMX is not supported.
|
|
|
|
## Specific Renderers
|
|
|
|
These are some notable software renderers:
|
|
|
|
- **[Build engine](build_engine.md)**: While not a "true 3D", this was a very popular [proprietary](proprietary.md) [BSP rendering](bsp.md) engine for older games like Duke Nukem 3D or Blood.
|
|
- **[BRender](brender.md)**: Old [proprietary](proprietary.md) commercial renderer used in games such as Carmageddon, Croc or Harry Potter 1.
|
|
- **[id Tech](id_tech.md)**: Multiple engines by [Id software](id.md) (later made [FOSS](foss.md)) used for games like [Quake](quake.md) included a software renderer.
|
|
- **[Irrlich](irrlicht.md)**: [FOSS](foss.md) game engine including a software renderer as one of its [backends](backend.md).
|
|
- **[Mesa](mesa.md)**: [FOSS](foss.md) implementation of [OpenGL](opengl.md) that includes a software rasterizer.
|
|
- **[small3dlib](s3l.md)**: [LRS](lrs.md) [C](c.md) 3D rasterizer, very simple.
|
|
- **SSRE**: The guy who wrote [LIL](lil.md) also made this renderer named Shitty Software Rendering Engine, accessible [here](http://runtimeterror.com/tech/ssre/).
|
|
- **[TinyGL](tinygl.md)**: Implements a subset of [OpenGL](opengl.md).
|
|
- Many old [games](game.md) implemented their own software renderers, so you can look there.
|
|
|
|
## See Also
|
|
|
|
- [pseudo/primitive 3D, 2.5D](pseudo3d.md) |