kanecvr wrote:The Voodoo series ability to do some geometry calculations would make sort of a "grandfather" of the modern GPU as it was able to offload some of the work from the CPU right?
As far as I know, the VooDoo cards could do no such thing. They were merely accelators in 2D-space.
kanecvr wrote:I don't remember other contemporaty 3d accelerators being able to do the same.
As far as I know, VooDoo wasn't particularly advanced at any point in time. It was just fast, really fast.
kanecvr wrote:Then again, this might be down to the glide APi and not the card itself? Is this correct?
Yes, that's what I think.
They just had a really efficient miniGL driver.
GLQuake is not a very good case for hardware-accelerated T&L in the first place, for 2 reasons:
1) Quake uses extremely lowpoly geometry, where you generally want to submit larger batches of polygon data to get any mileage out of T&L.
2) Quake uses a BSP tree algorithm, which splits up each sector down to single polygons to determine visibility.
This means polygons are submitted to the pipeline one at at time, from system memory. This is a worst-case scenario for hardware T&L. Later BSP-based engines would use 'leafy' BSP trees, where they didn't split things down to individual polygons, but to small batches of polygons, to increase performance on T&L hardware.
A TNT may be slow on a 486 for a different reason: Because it's considerably more advanced than a VooDoo, the CPU also has to set up a lot more stuff for every draw operation. That may not be an issue on the Pentium II+ machines that it targeted, but the driver overhead might be too much for a 486. It could also be that because the driver is much newer than the VooDoo ones, no care was taken to optimize code for the extremely slow FPU of a 486, and they just assumed a fast FPU like on a Pentium or better. The software version of Quake is unplayable on 486 systems for the exact same reason.
If you want to see 'grandfathers' of the GPU, I think early SGI systems with custom co-processors for geometry would be where it's at.
Or perhaps even the IBM Professional Graphics Controller: https://en.wikipedia.org/wiki/Professional_Gr … hics_Controller
It was basically a 'PC on a stick': it had its own memory and 8088 CPU. You could upload programs to it, that would draw into the video memory autonomously.
The Amiga would also be a nice candidate: It had the 'copper' co-processor', which could run simple programs. And the blitter chip, which could draw lines and perform floodfill.
The blitter could be programmed to render polygons by first drawing the outline, and then flood-filling it. Such a program could be executed by the copper, so you could consider the copper+blitter combination an early form of a GPU: you could batch up graphics tasks with the CPU into copperlists, and they would execute without any intervention from the CPU.