You can download the Voodoo 2 programming manual which is only around 250-something pages long. The Voodoo2 was fixed function; you loaded assets into the voodoo memory then called functions to operate on those assets. The driver takes care of those two roles by loading and managing the assets in the voodoo memory and an API to program the registers on the card to execute functions on the loaded assets. There were more steps involved with geometry processing which happened in the driver but I am unsure if those were handled in user space by the libraries the application called or the driver code itself.<p>This isn't 250 something pages, only 132 so maybe I was wrong, but its a good look into how the Voodoo2 worked: <a href="https://www.dosdays.co.uk/media/3dfx/voodoo2.pdf" rel="nofollow">https://www.dosdays.co.uk/media/3dfx/voodoo2.pdf</a><p>See also: <a href="https://3dfxarchive.com/reference.htm" rel="nofollow">https://3dfxarchive.com/reference.htm</a><p>A fun tidbit is the voodoo2 has a 2D mode but was not VESA compliant so it could not be used in a PC without being tied to a VESA card for 2D graphics. I believe that ability was there for custom and non-pc platforms.

From what I’ve seen, a lot of 90s driver work was exactly that mix of partial docs, trial-and-error with registers, and mailing some engineer at the card vendor hoping they’d admit to a bug. It wasn’t glamorous, but it’s kind of wild how much of it came down to persistence and a bit of luck

During that time, I had a job for a major games company doing nothing but developing Windows graphics card drivers. They were moderately complex beasts (enormously complex compared to other device drivers), but not really that huge of a thing.<p>The biggest effort about them was reverse-engineering certain cards. The games often used very strange video settings, and the card manufacturers had poor, sometimes no, documentation about their operation at a low level.

These were pretty proprietary I remember.