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?

  • 1
    $\begingroup$ "Why is a graphics processing unit not at universal processing unit", is that you question? $\endgroup$
    – Andreas
    Oct 2, 2016 at 14:02
  • 1
    $\begingroup$ @Andreas No, my question is as it's stated in the post. Why are rasterizers still a hardware part, when they could be done in software (in fact they already could be done with OpenCL, or compute shaders). Question is why it is not common... maybe it's simply performance, I don't know, that's why I'm asking... $\endgroup$
    – zduny
    Oct 2, 2016 at 14:09
  • $\begingroup$ You can bypass the rasterization and implement your own rasterizer with compute units on modern GPU's and I in fact know people doing this for specific purposes. $\endgroup$
    – JarkkoL
    Oct 3, 2016 at 13:18
  • $\begingroup$ Rasterizers convert vector polys into a bunch of pixels that we can light. When we no longer have pixels, or stop using vector geometry, we will no longer need rasterizers. No matter what the rest of your pipeline looks like, at the end of the day (or frame), you need pixels. The rasterizer just tells us which pixels we are concerned about for a given triangle. All of that is programmable - if you want different output from the rasterizer, send different triangles its way. Or just draw everything to a render texture in a compute shader and blit it to the screen with a view-aligned quad. $\endgroup$
    – 3Dave
    Oct 5, 2016 at 22:59

1 Answer 1


In short, performance reasons are why they aren't programmable.

History and Market

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.

Attempts at Software Rasterizers

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.

Technical Issues with Software Rasterization

There are many issues that were faced in the Nvidia paper. Here are some of the most important issues with software rasterizers though:

Major Issues

  • 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.

  • $\begingroup$ I dont think you need to store the subpixel samples if box filttering is enough then you can just do running averages. $\endgroup$
    – joojaa
    Oct 2, 2016 at 19:41
  • 2
    $\begingroup$ I suspect texture sampling and cache are probably also areas where hardware implementations allows performance otherwise impossible to achieve with software implementations. $\endgroup$ Oct 3, 2016 at 2:37
  • 3
    $\begingroup$ @aces One other item worth mention is power. Dedicated hardware will do the same job typically with a fraction of the power budget and, with power throttling already an issue, especially on mobile devices, going fully programmable would make it vastly worse. $\endgroup$
    – Simon F
    Oct 3, 2016 at 12:02
  • $\begingroup$ @JulienGuertault Fair point, but I would think this is mostly applicable to MSAA. There test results seem to indicate that this isn't a huge issue when everything fits on on-chip memory (although this could have some performance impact regardless). $\endgroup$
    – aces
    Oct 4, 2016 at 3:47
  • $\begingroup$ @SimonF I think that's a great point as well. I included it in the answer. $\endgroup$
    – aces
    Oct 4, 2016 at 3:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.