drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2025-02-12 23:09:00 +01:00
parent 85321afd67
commit ec4393d204
17 changed files with 1952 additions and 1945 deletions
Download patch file Download diff file Expand all files Collapse all files

12
sw_rendering.md
View file

@ -1,12 +1,14 @@
# Software Rendering
[Software](software.md) (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the help of [graphics card](gpu.md) (GPU), or in other words computing images only with [CPU](cpu.md). Most commonly the term means rendering [3D graphics](3d_rendering.md) but may as well refer to other sorts of graphics such as drawing [fonts](font.md) or [video](video.md). Before the invention of GPU card all rendering was done in software of course -- games such as [Quake](quake.md) or Thief were designed with SW rendering and only added optional GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md), for rasterization is the basis of current real-time 3D graphics.
[Software](software.md) (SW) rendering refers to [rendering](rendering.md) [computer graphics](graphics.md) without the aid of [graphics card](gpu.md) (GPU), or in other words computing images only with the [CPU](cpu.md). The opposite is called *GPU accelerated* or *[hardware](hw.md) accelerated* rendering. Most commonly the term SW rendering means rendering [3D graphics](3d_rendering.md) but may as well refer to other types of graphics such as drawing [fonts](font.md) or [video](video.md). Before the invention of GPU cards all rendering was done in software of course -- games such as [Quake](quake.md) or Thief were designed with SW rendering and only added optional GPU acceleration later. SW rendering for traditional 3D graphics is also called software [rasterization](rasterization.md), for rasterization is the basis of current real-time 3D graphics.
SW rendering has advantages and disadvantages, though from our point of view its advantages prevail (at least given only capitalist GPUs exist nowadays). Firstly it is **much slower** than GPU graphics -- 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 workable FPS. Nevertheless thanks to the ginormous speeds of today's CPUs simple fullscreen SW rendering can be pretty fast on PCs and achieve even above 60 FPS; on slower CPUs (typically [embedded](embedded.md)) SW rendering is usable normally at around 30 FPS if resolutions are kept small.
It must be noted that SW rendering doesn't mean the program is never touching [GPU](gpu.md) at all, in fact most personal computers nowadays REQUIRE some kind of GPU to even display anything. Even if GPU is involved in presentation of the computed image, we still talk about SW rendering as long as the image was computed by the CPU. Of course there may exist a gray area where SW and hardware accelerated rendering are combined.
On the other hand SW rendering is more [portable](portability.md) (as it can be written purely 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. SW rendering is the [KISS](kiss.md) approach.
SW rendering has advantages and disadvantages, though from [our](lrs.md) point of view its advantages prevail (at least given only capitalist GPUs exist nowadays). Firstly it is **much slower** than GPU graphics -- 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, no [antialiasing](antialiasing.md), [nearest neighbour](nn.md) texture filtering, no [mipmaps](mipmap.md), ...) to allow workable FPS. Nevertheless thanks to the ginormous speeds of today's CPUs simple fullscreen SW rendering can be pretty fast on PCs and achieve even above 60 FPS; on slower CPUs (typically [embedded](embedded.md)) SW rendering is usable normally at around 30 FPS if resolutions are kept small.
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, i.e. it is more flexible. This may include [splatting](splatting.md), [raytracing](raytracing.md) or [BSP rendering](bsp.md) (and many other ["pseudo 3D"](pseudo3d.md) techniques).
On the other hand SW rendering is **more [portable](portability.md)** (as it can be written purely 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 do, 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. SW rendering is the **[KISS](kiss.md) approach**, which also implies it's **more [future proof](future_proof.md)** etc. Furthermore SW rendering is **more predictable** -- this is because GPUs are highly [magical](magic.md) devices [optimized](optimization.md) to work well under certain assumptions (e.g. not drawing too many small triangles) and each GPU (or even the same GPU with different drivers) may react differently to what we're rendering, so even though GPU performance will be higher, it will be much more difficult to be kept stable and predictable over a wide range of different GPUs and drivers.
SW rendering may also utilize (at least more easily and without penalties) 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, i.e. it is **more flexible**. This may include [splatting](splatting.md), [raytracing](raytracing.md) or [BSP rendering](bsp.md) (and many other ["pseudo 3D"](pseudo3d.md) techniques) and even completely different rendering paradigms such as [frameless rendering](frameless.md).
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)).
@ -14,8 +16,6 @@ For simpler and even somewhat more complex graphics **purely software rendering
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.
## Programming A Software Rasterizer