Yes. Probably even Voodoo 1 with late drivers.

Why could my GLQuake peformance be lacklustre? Should I be using the MiniGL driver instead of the OpenGl ICD?

appiah4 wrote on 2020-06-15, 16:16:

Why could my GLQuake peformance be lacklustre? Should I be using the MiniGL driver instead of the OpenGl ICD?

With weaker CPUs you certainly should.

appiah4 wrote on 2020-06-15, 15:34:

I know that Voodoo 3 drivers have 3DNow optimizations.. But do Voodoo Banshee drivers have these also? I'm just asking because my K6-2/500 with a Voodoo Banshee performs pretty lacklustre compared to a Pentium II 333 with a Riva 128 in GLQuake, so I was scratching my head..

I have just checked and the Opengl ICD in the latest 3dfx Voodoo Banshee V1.04.00 driver package does not contain even a single 3DNow! instruction. It's rather easy to check this with BIEW or any other binary viewer that has disassembly option.
3Dnow! instruction blocks have to start/end with EMMS/FEMMS instruction because the MMX/3DNow! registers are mapped onto the x87 stack.
Since FEMMS is much faster than EMMS and all processors that support 3Dnow! also support FEMMS, 3Dnow! code almost always use FEMMS. The hex code of FEMMS is 0x0F0E so it can be searched. 3dfxOGL.dll only contains large blocks of x87 code that are much faster on the pipelined FPU of P5/P6. While K6 has a low latency FPU (most frequent x87 instructions have only 2 clock latency compared to 3/5 clocks of P6) the non-pipelined PFU of K6 does not like long chains of x87 code.
The low latency FPU of K6 likes much better mixed integer/floating point code as could be found in spreadsheet/business applications.

While the files that belong to Windows/Directx driver really contain 3Dnow! optimized code:

This is also true for Glide drivers. Both glide2x.dll and glide3x.dll contain 3Dnow! code:

Falcosoft wrote on 2020-06-15, 22:16:

I have just checked and the Opengl ICD in the latest 3dfx Voodoo Banshee V1.04.00 driver package does not contain even a single […]
Show full quote

appiah4 wrote on 2020-06-15, 15:34:

I know that Voodoo 3 drivers have 3DNow optimizations.. But do Voodoo Banshee drivers have these also? I'm just asking because my K6-2/500 with a Voodoo Banshee performs pretty lacklustre compared to a Pentium II 333 with a Riva 128 in GLQuake, so I was scratching my head..

I have just checked and the Opengl ICD in the latest 3dfx Voodoo Banshee V1.04.00 driver package does not contain even a single 3DNow! instruction. It's rather easy to check this with BIEW or any other binary viewer that has disassembly option.
3Dnow! instruction blocks have to start/end with EMMS/FEMMS instruction because the MMX/3DNow! registers are mapped onto the x87 stack.
Since FEMMS is much faster than EMMS and all processors that support 3Dnow! also support FEMMS, 3Dnow! code almost always use FEMMS. The hex code of FEMMS is 0x0F0E so it can be searched. 3dfxOGL.dll only contains large blocks of x87 code that are much faster on the pipelined FPU of P5/P6. While K6 has a low latency FPU (most frequent x87 instructions have only 2 clock latency compared to 3/5 clocks of P6) the non-pipelined PFU of K6 does not like long chains of x87 code.
The low latency FPU of K6 likes much better mixed integer/floating point code as could be found in spreadsheet/business applications.
icd_fpu.jpg

While the files that belong to Windows/Directx driver really contain 3Dnow! optimized code:
directx_3dnow.jpg

This is also true for Glide drivers. Both glide2x.dll and glide3x.dll contain 3Dnow! code:
glide_3dnow.jpg

I'm sorry for the OT post, but is there an application like BIEW that works in Windows or DOS? I've been looking for something like this that will actually show the instructions being used, but I'm not that familiar with code or programming. I'd prefer a modern Windows application but I'd settle for DOS if it would just show the instructions the way BIEW does.

Ozzuneoj wrote on 2020-06-15, 23:28:

I'm sorry for the OT post, but is there an application like BIEW that works in Windows or DOS? I've been looking for something like this that will actually show the instructions being used, but I'm not that familiar with code or programming. I'd prefer a modern Windows application but I'd settle for DOS if it would just show the instructions the way BIEW does.

The Biew version I used is actually a Win32/64 console application (as you can see "biew.exe" is displayed as window caption on the screenshots).
Later it has been renamed to to "beye" ( it's new to me) but old biew versions can still be downloaded:
https://sourceforge.net/projects/beye/

For DOS there is/was Hacker's view (Hiew):
http://old-dos.ru/files/file_184.html

Edit: I have just noticed that Biew/Beye also has a DOS32 version that can be downloaded from the Sourceforge site:
https://sourceforge.net/projects/beye/files/biew/6.1.0/

Falcosoft wrote on 2020-06-15, 22:16:

I have just checked and the Opengl ICD in the latest 3dfx Voodoo Banshee V1.04.00 driver package does not contain even a single […]
Show full quote

appiah4 wrote on 2020-06-15, 15:34:

I know that Voodoo 3 drivers have 3DNow optimizations.. But do Voodoo Banshee drivers have these also? I'm just asking because my K6-2/500 with a Voodoo Banshee performs pretty lacklustre compared to a Pentium II 333 with a Riva 128 in GLQuake, so I was scratching my head..

I have just checked and the Opengl ICD in the latest 3dfx Voodoo Banshee V1.04.00 driver package does not contain even a single 3DNow! instruction. It's rather easy to check this with BIEW or any other binary viewer that has disassembly option.
3Dnow! instruction blocks have to start/end with EMMS/FEMMS instruction because the MMX/3DNow! registers are mapped onto the x87 stack.
Since FEMMS is much faster than EMMS and all processors that support 3Dnow! also support FEMMS, 3Dnow! code almost always use FEMMS. The hex code of FEMMS is 0x0F0E so it can be searched. 3dfxOGL.dll only contains large blocks of x87 code that are much faster on the pipelined FPU of P5/P6. While K6 has a low latency FPU (most frequent x87 instructions have only 2 clock latency compared to 3/5 clocks of P6) the non-pipelined PFU of K6 does not like long chains of x87 code.
The low latency FPU of K6 likes much better mixed integer/floating point code as could be found in spreadsheet/business applications.
icd_fpu.jpg

While the files that belong to Windows/Directx driver really contain 3Dnow! optimized code:
directx_3dnow.jpg

This is also true for Glide drivers. Both glide2x.dll and glide3x.dll contain 3Dnow! code:
glide_3dnow.jpg

Oh wow! Thanks for this amazing post that confirms what I thought all along, the OpenGL ICD is not 3DNow! Optimized! How the fuck did 3dfx do this? SMH.

So I guess I should try running GLQuake with Voodoo2 MiniGL and Quake II with 3dfx OpenGL options? Would that even work on a Banshee?

Also, as far as anybody knows, do any 3rd party/community drivers have the ICD compiled for 3DNow! ?

AFAIK 3dfx don't have true OpenGL ICD. What they call "ICD" is just a sophisticated GL-to-Glide wrapper, which works with everything, unlike MiniGL.

The Serpent Rider wrote on 2020-06-16, 07:49:

AFAIK 3dfx don't have true OpenGL ICD. What they call "ICD" is just a sophisticated GL-to-Glide wrapper, which works with everything, unlike MiniGL.

You are right in that 3dfxOGL.dll depends on glide3x.dll and uses many exports of glide3 library. But many OpenGL functions implemented in 3dfxOGL.dll are self-contained and contains FPU/x87 heavy calculations. Even if you just compare the file sizes of 3dfxOGL.dll (1268 KB) and glide3x.dll (281 KB) it's evident that 3dfxOGL.dll is not simply a 'GL-to-Glide wrapper'. To achieve full OpenGL 1.1 compatibility the implemented functionality provided by glide3 seemingly was not enough.

Still nobody answered my question about whether MiniGL works with Banshee cards or not.. 😁

EDIT: A bit of RTFM gave me the answer: Yes, it does.

If the OpenGL is calling Glide for some things, then it is probably benefiting from 3DNow indirectly. It's interesting that they didn't use SIMD for the functions within the OpenGL ICD though.