amadeus777999 wrote on 2020-02-06, 15:05:

Great comparison!

I overclocked the P60 I had to 75mhz and will scan for the screenshots that I took. It was not really fast though. 80mhz did only work for a short amount of time - the northbridge needed cooling from 75 upwards.

But since I assume that the P60 doesn't have any multiplier, that would've been at 75MHz fsb, right?

Yes, a full 75mhz - but don't expect any performance wonder.
I could not find the screenshots of speedsys but I still have my scoresheet. Maybe I can dig out the screens later. Notable in performence improvement was Blood. It was the only software where true performance outshone extrapolated one - around 9% advantage. (Extraolated scores in parenthesis.)

Doom, Blood and Duke3D score will scale with overclocked PCI bus. In fact, Doom has huge bus speed dependency, but the Build engine dependency is less pronounced.

I gotta admit I was expecting a tie. The P66 with the win, was a nice surprise.

I seem to remember PC Magazine or some other magazine of the era testing the P75 against the P66 when it first came out and the outcome being overall slightly in favor of the P66 due to bus speed. It's just a vague memory, I could be wrong. I tried searching for a few minutes, but couldn't find an issue. 🙁

The Serpent Rider wrote on 2020-02-07, 17:09:

Doom, Blood and Duke3D score will scale with overclocked PCI bus. In fact, Doom has huge bus speed dependency, but the Build engine dependency is less pronounced.

It's because DOOM is quite inefficient when finalising the framebuffer to VGA. It is doing 16bit transfers instead of 32bit which would have been optimal for modern VL-Bus/PCI cards. That's why it is more dependant on the bus speed as it has to do twice amount of transfers to write the same amount of pixels.

Not that familiar with Blood/Duke3D engines.

To settle down this "dispute" I've done a benchmark testing of PCI from 16.6 MHz to 50 MHz on my 5x86 (as it can set PCI divider between 1:1 to 1:2 and can be easily overclocked)

As you can see Quake shows almost zero dependency on PCI bus clock. Even 16.6 MHz PCI doesn't hurt it much as all the effort goes to rendering and retiring of the buffer is very optimised. On the other hand the DOOM (and obviously vidspeed measuring raw speed) displays relatively high dependency on the PCI clock. Ignore absolute values as this is with default (non-optimal BIOS settings). It is the relative differences that matter here.

Doom has 24% performance drop and Quake has 13% performance drop, and your analysis is that the former “displays relatively high dependency” and the latter “shows almost zero dependency”?

appiah4 wrote on 2020-02-08, 08:27:

Doom has 24% performance drop and Quake has 13% performance drop, and your analysis is that the former “displays relatively high dependency” and the latter “shows almost zero dependency”?

There's a difference in CPU speed as well in that diagram. According to the diagram at the same CPU speed differences are much less between 1:2 and 1:2 FSB:PCI clock ratio.

appiah4 wrote on 2020-02-08, 08:27:

Doom has 24% performance drop and Quake has 13% performance drop, and your analysis is that the former “displays relatively high dependency” and the latter “shows almost zero dependency”?

The CPU / mem clock changed as well. So you need to read the graph like this:

Doubling PCI clock brings:

@133MHz from 16.6 to 33.3 MHz - in Doom +8%, in Quake + 0.07%
@166MHz from 20 to 40 MHz - in Doom +7.67%, Quake +0.07%
@150 Mhz from 25 to 50 MHz - in Doom +6.22, Quake +0%

I think the Quake results are within a margin of error. That proves the Quake (and PCBench) is at least at this level of CPU performance and 320x200 pretty much insensitive to PCI clock (unlike Doom or 3Dench)

Ahh I did not notice the internal CPU speed difference, sorry.

It's because DOOM is quite inefficient when finalising the framebuffer to VGA

Yes, that's probably related to Doom Mode X shenanigans. They are not present in other Doom engine games, maybe except Hacx: Twitch 'n Kill.

I think John Carmack once said that the very early VL-Bus cards in 1992/3 back when they created Doom did not handle 32bit quite well as they were just scaled ISA 16-bit designs. Also due to size of artwork in Doom using 32bit would lead to some alignment issues when transferring odd number of them. Thus 16bit was a adequate choice for average 486SX-33 + low end VLB Cirrus Logic for which was DOOM was likely designed for.

Anyway, DOOM is not as efficient as it could be on a Pentium-class CPUs/cards. Yet it is simple and gameplay is capped at 35fps so it is working fine. On the other hand the Quake is pretty much CPU/FPU/Mem benchmark on this gen of CPUs and the bus/VGA plays hardly any role. I estimate you'd need at least to triple CPU performance compared to P75 to notice the PCI performance. By then there is P6 architecture with write combining and other tricks to optimise for writes if not 3D graphics era with completely different issues.

mpe wrote on 2020-02-08, 11:33:

I think John Carmack once said that the very early VL-Bus cards in 1992/3 back when they created Doom did not handle 32bit quite well as they were just scaled ISA 16-bit designs. Also due to size of artwork in Doom using 32bit would lead to some alignment issues when transferring odd number of them. Thus 16bit was a adequate choice for average 486SX-33 + low end VLB Cirrus Logic for which was DOOM was likely designed for.

Anyway, DOOM is not as efficient as it could be on a Pentium-class CPUs/cards. Yet it is simple and gameplay is capped at 35fps so it is working fine. On the other hand the Quake is pretty much CPU/FPU/Mem benchmark on this gen of CPUs and the bus/VGA plays hardly any role. I estimate you'd need at least to triple CPU performance compared to P75 to notice the PCI performance. By then there is P6 architecture with write combining and other tricks to optimise for writes if not 3D graphics era with completely different issues.

Good points if true. Otherwise, they'd have been tuning the game for better benchmark results on future platforms, not best performance on current platforms.

mpe wrote on 2020-02-08, 01:12:

It's because DOOM is quite inefficient when finalising the framebuffer to VGA. It is doing 16bit transfers instead of 32bit whic […]
Show full quote

The Serpent Rider wrote on 2020-02-07, 17:09:

Doom, Blood and Duke3D score will scale with overclocked PCI bus. In fact, Doom has huge bus speed dependency, but the Build engine dependency is less pronounced.

It's because DOOM is quite inefficient when finalising the framebuffer to VGA. It is doing 16bit transfers instead of 32bit which would have been optimal for modern VL-Bus/PCI cards. That's why it is more dependant on the bus speed as it has to do twice amount of transfers to write the same amount of pixels.

Not that familiar with Blood/Duke3D engines.

To settle down this "dispute" I've done a benchmark testing of PCI from 16.6 MHz to 50 MHz on my 5x86 (as it can set PCI divider between 1:1 to 1:2 and can be easily overclocked)

graph.jpg

As you can see Quake shows almost zero dependency on PCI bus clock. Even 16.6 MHz PCI doesn't hurt it much as all the effort goes to rendering and retiring of the buffer is very optimised. On the other hand the DOOM (and obviously vidspeed measuring raw speed) displays relatively high dependency on the PCI clock. Ignore absolute values as this is with default (non-optimal BIOS settings). It is the relative differences that matter here.

From where did you get the info about the word transfers and could you eplain what "finalising the framebuffer" means?

appiah4 wrote on 2020-02-05, 15:37:

But tell him to do it, for science!

Talked him down a bit 😉 Going to pick up those boards tomorrow afternoon. So assuming the stuff actually works I will have contemporary Asus SiS501 boards for So4 and 5 to test with. No P75, but clocking down any P54 works there. Also have a P60, not P66, so still need to check if it runs at 66MHz. Will update when I get the stuff and if it works I'll run some simple DOS benchmarks.

amadeus777999 wrote on 2020-02-08, 12:27:

From where did you get the info about the word transfers and could you eplain what "finalising the framebuffer" means?

By "finalising" I mean the blit operation where you copy the contents from one of RAM framebuffers where the image is prepared into the VRAM framebuffer to be displayed on the screen.

The info about 16bit transfers is from I_UpdateBox implementation in the original DOS source code, resp. amazing Fabien Sanglard's book "Game Engine Black Book".

dionb wrote on 2020-02-08, 13:06:

Talked him down a bit 😉 Going to pick up those boards tomorrow afternoon. So assuming the stuff actually works I will have contemporary Asus SiS501 boards for So4 and 5 to test with. No P75, but clocking down any P54 works there. Also have a P60, not P66, so still need to check if it runs at 66MHz. Will update when I get the stuff and if it works I'll run some simple DOS benchmarks.

Good one. I only have SiS501 based Socket 4 motherboard (ECS SiS501). In default config it is a tiny bit slower than the 430LX Batman. However, the dual-bank cache on my board can be upgraded to 2MB which gives it a very nice boost and beats the Intel board.

I expect you should see a very similar results when comparing SiS501 based S4 vs S5.

mpe wrote on 2020-02-08, 13:30:

amadeus777999 wrote on 2020-02-08, 12:27:

From where did you get the info about the word transfers and could you eplain what "finalising the framebuffer" means?

By "finalising" I mean the blit operation where you copy the contents from one of RAM framebuffers where the image is prepared into the VRAM framebuffer to be displayed on the screen.

The info about 16bit transfers is from I_UpdateBox implementation in the original DOS source code, resp. amazing Fabien Sanglard's book "Game Engine Black Book".

Interesting, Thanks.
I only "knew" the function from Alexey's pcdoomv2 and was not aware that it was a "legitimate" implementation.

dionb wrote on 2020-02-08, 13:06:

appiah4 wrote on 2020-02-05, 15:37:

But tell him to do it, for science!

Talked him down a bit ;) Going to pick up those boards tomorrow afternoon. So assuming the stuff actually works I will have contemporary Asus SiS501 boards for So4 and 5 to test with. No P75, but clocking down any P54 works there. Also have a P60, not P66, so still need to check if it runs at 66MHz. Will update when I get the stuff and if it works I'll run some simple DOS benchmarks.

Were you planning on posting your test results, or were they in another thread?

feipoa wrote on 2020-04-13, 07:40:

dionb wrote on 2020-02-08, 13:06:

appiah4 wrote on 2020-02-05, 15:37:

But tell him to do it, for science!

Talked him down a bit 😉 Going to pick up those boards tomorrow afternoon. So assuming the stuff actually works I will have contemporary Asus SiS501 boards for So4 and 5 to test with. No P75, but clocking down any P54 works there. Also have a P60, not P66, so still need to check if it runs at 66MHz. Will update when I get the stuff and if it works I'll run some simple DOS benchmarks.

Were you planning on posting your test results, or were they in another thread?

No test results because the P54SP4 is completely dead, nothing I've been able to do even gets it starting to POST. Ruled out BIOS (flashed on known-good chip), power delivery, bent chipset pins, bad cache etc. I'm afraid I've given up on it :'(