To expound on this comment: SDL1 defaults to fully software rendered output. You can hack in opengl hardware rendering, but it's fairly common for SDL1 games and such to be fully software rendered and run fine.

SDL2 in general is hardware rendered.

SDL1 is a good counter-example to "software rendering isn't quick enough anymore". You can make perfectly performant 2d games with sdl1's software rendering... 3d, not so much.

People usually use SDL1 with OpenGL, and I don't understand what part of it is "hack". Is using OpenGL with a manually created context with tens of platform ifdefs less hacky? Or is EGL/glut/<your favorite wrapper> the one true way of doing things?

It's not a hack in that it's held together by tape, precarious, or any such thing; it's a hack because it's going around the back of SDL to do the graphics, even though SDL is supposed to do all the graphics for you.

Perhaps my wording was poor. It's more of a hack than in SDL2, where all the SDL functions support hardware rendering with no need to touch OpenGL directly ever.

The general point still stands that you can write performant software rendering in SDL1.

I am talking about the layers below SDL. The layers that give rise to questions like will the graphics card be supported on my favorite OS if I buy this new computer?. These layers are responsible for detecting and configuring your adapters & monitors, setting the resolution, colour depth, interrupts for vsync, dma for fast frame copying, etc. If these things do not work right, you are in for a sad sad desktop experience, even if your CPU were fast enough to do all the 3D magic you want.

Hilariously, using software SDL for your framebuffer (at least on X.org) will be much slower than using OpenGL PBOs. Don't talk about hardware acceleration here -- all we're doing is transferring a finished frame to the display. At this point, we already need much more than the "small" amount of code to implement KMS. Can it break? Yes it can. Does it break? Yes it does. Graphics driver issues are still among the most common problems I witness people struggle with, as far as getting their OS to run smoothly goes.

You use SDL precisely to not care about layers below. SDL 2 will select fastest mechanism to get your software rendered frame to the screen.

I care about the layers below, because they affect people, and they affect me. If the layers below are broken, SDL does not fix it.