feipoa wrote on 2019-10-07, 08:23:(...) the take away message for me was the comment that Quake 2, with the S3 Virge GX and a 1 GHz Pentium, plays about the same as a Pentium 166 in software mode. This card seems like a fairly impressive decelerator. Anyone here actually use it for 3D "acceleration" back in the day?
I'm not sure that you got the point. The card is pixel fill-rate limited so the 1GHz CPU doesn't give you any additional frame per second in comparison with something like 266MHz Pentium II (a CPU that OEMs often used to combine with Virge GX/GX2). I used a 1GHz P3 CPU just to be sure that this is the best fill-rate performance you can get out of the card (yes, I'm the guy from the video).
feipoa wrote:Am I doing something wrong? Why would there be an S3 Quake minigl if it is slower than software mode?
Nope, you did it right. There is no benefit for you to use DX wrapper for GLQuake. You have too slow CPU.
Basically, CPU handles all the game logic (position of all items/enemies, collisions...) and 3D scene culling (BSP trees...) in the game - this is the same for both software rendered and accelerated version. The difference is in further rendering stages:
- Geometry processing (2D projection of the 3D scene)
- Triangle setup
- Drawing the calculated polygons
The software version of Quake does all parts in a heavily optimized way that is tailored for the level of precision and type of rendering that is used by the game. Nothing more, nothing less. On the other side, the 3D accelerated version uses libraries that can be used for the game as well as CAD software. These libraries are more versatile, can do more and need more performance on the hardware side. Just try running GLQuake with the Microsoft's OpenGL software renderer to see what I'm talking about (you will see the performance far lower than with the internal software mode... even if texture filtering is disabled).
So...
- You use universal graphics libraries to render the game (higher CPU overhead)
- In addition to that, there is a wrapper translating all calls to another graphics library (additional CPU overhead)
Virge is a very simple chip accelerating just the rasterization part of the rendering. It does not have a geometry unit (typical for any card of that era outside hi-end CAD segment) and it does not have even a triangle setup engine (like ATI Rage I/II and other some other early cards). That means that all triangles in the projection must be split into spans based on slope data for each axis (X, Y, Z, A, U, V) and these slopes must be calculated by CPU... and again, it is done using a universal way not tailored for the precision required by this particular game (additional CPU overhead).
Although the Virge DX/GX/GX2 has low textured pixel fill-rate performance (btw all three chips have the same performance per MHz; the only difference is between EDO and synchronous memory chips... surprisingly, EDO version is always faster on the same clock), with the 133MHz Pentium (not a crippled one), you cannot fully utilize the card. The frame rate is limited already on the geometry and triangle setup so lowering the resolution doesn't help much.
I've tested different combinations of 3D accelerators and CPUs to be sure that Pentium 133MHz is not powerful enough. Early Direct3D APIs have high CPU overhead, which gives a big performance advantage for 3Dfx Voodoo Graphics if Glide is an option. With the slow CPU, you should at least use a 3D accelerator that has hardware triangle setup engine.
Viper Racing
512x384 / P133
5.4 fps Rage II+
8.7 fps Virge GX
31.3 fps Voodoo2
512x384 / P166MMX
7.9 fps Rage II+ (+46%)
15.9 fps Virge GX (+83%)
41.6 fps Voodoo2 (+33%)
I wrote more about it on my blog: https://swarmik.tumblr.com/post/184625185139/ … -cpus-1997-1998