My little spot of nuance on this reply would be that the point of starting in software would not be to aim for a fast or feature-rich implementation. That seems

My little spot of nuance on this reply would be that the point of starting in software would not be to aim for a fast or feature-rich implementation. That seems to be the sticking point of the replies in favor of going hardware-first - that "we don't optimize the same way anymore". But nobody was asking about optimizing! People seem to go performance-brained when they talk about graphics because they read about John Carmack once. Then they go right back to their Javascript frameworks. Like any student engineering project, "baby's first rasterizer" would emphasize a combination of concepts and motions - a path to take, to get to a result that can be tested. We don't even have to use Bresenham now - deriving the rasterized line from linear interpolation is mathematically more sound and no sweat for modern CPUs. But it might be pedagogically useful to compare the two to explain quality vs performance tradeoffs, ones that were made historically and those that are still in use today.