Computer Graphics Stack Exchange is a question and answer site for computer graphics researchers and programmers. It only takes a minute to sign up.
Sign up to join this community
Despite advancements modern GPUs still have fixed rasterizers. Highly customizable, with programmable shaders but nevertheless not fully programmable.
Why is that?
Why can't GPUs be simply massively parallel devices with universal computing units where rasterizer is just a software for that device provided by the user?
Is having fixed function hardware so beneficial performance-wise that such approach is unfeasible?
In short, performance reasons are why they aren't programmable.
In the past, there used to be separate cores for vertex and fragment processors to avoid bloated FPU designs. There were some mathematical operations you could only do in fragment shader code for instance (because they were mostly only relevant for fragment shaders). This would produce severe hardware bottlenecks for applications that didn't max out the potential of each type of core.
As programmable shaders became more popular, universal units were introduced. More and more stages of the graphics pipeline were implemented in hardware to help with scaling. During this time, GPGPU also became more popular, so vendors had to incorporate some of this functionality. It's still important to note though that the majority of the income from GPUs were still video games, so this couldn't interfere with performance.
Eventually a big player, Intel, decided to invest in programmable rasterizers with their Larrabee architecture. This project was supposed to be groundbreaking, but the performance was apparently less than desired. It was shut down, and parts of it were salvaged for Xeon Phi processors. It's worth noting though that the other vendors haven't implemented this.
There have been some attempts at rasterization through software, but they all seem to have issues with performance.
One notable effort was an attempt by Nvidia in 2011 in this paper. This was released close to when Larrabee was terminated, so it's very possible that this was a response to that. Regardless, there are some performance figures in this, and most of them show performance multiple times slower than hardware rasterizers.
There are many issues that were faced in the Nvidia paper. Here are some of the most important issues with software rasterizers though:
Interpolation: The hardware implementation generates interpolation equations in specialized hardware. This is slow for the software renderer since it had to be done in the fragment shader.
Anti-aliasing: There were also performance issues with anti-aliasing (specifically with memory). Information regarding the sub-pixel samples must be stored on-chip memory, which isn't enough to hold this. Julien Guertault pointed out that the texture cache/cache may be slower with software. MSAA certainly has issues here because it overflows the cache (the non-texture caches) and goes into memory off of the chip. Rasterizers compress data that is stored in that memory, which also helps with performance here.
Power Consumption: Simon F pointed out that power consumption would be lower. The paper did mention that custom ALUs are in rasterizers (which would reduce power consumption), and this would make sense since fragment and vertex processing units in the past used to have custom instruction sets (so likely custom ALUs as well). It certainly would be a bottleneck in many systems (e.g., mobile), although this has implications beyond performance.
TL;DR: there are too many inefficiencies that software rendering can't past, and these things add up. There are also many larger limitations, especially when you are dealing with VRAM bandwidth, synchronization problems, and extra computations.
