Smucek wrote on 2022-09-16, 23:14:

Voodoo 2 12 MB SLI on Pentium III 933 MHz with 512 MB 133 MHz SD RAM.

A very respectable score!

Very very strange scores for my latest benchmarking run. I've just started and only two cards in, but this is what makes little sense. 3 runs each for an average on AGP 7800 GS+ from 2006 and AGP HD 3850 from 2008 =

AGP 7800 GS+ = 38163 points
AGP HD 3850 = 33503 points

In every other benchmark or gameplay run the AGP HD 3850 is leagues ahead.. Why the heck is 3dm99 giving higher scores to the 7800? So confused!

It makes perfect sense to me as I have run benchmarks with my HD3850 AGP then 7800GS on the same hardware.

The HD3850 should beat the 7800 in 3dmark2001 and 2003 and so on. chances the driver overhead is a lot bigger for the 3850, it needs a more powerful cpu to push it.
Another possibility is the driver is simply not optimised for running ancient dx6 or dx7 benchmarks.

On Super socket 7 You will get higher scores in 3dmark2000 with a gf2 or gf3 than a ti4200 or faster card.

Actually I got 30+fps more in doom3 with 7800gs than Hd3850, 130fps vs 96fps that was with overclocked Pentium M on Asus socket 478.

Imperious wrote on 2022-10-09, 13:07:

It makes perfect sense to me as I have run benchmarks with my HD3850 AGP then 7800GS on the same hardware. […]
Show full quote

It makes perfect sense to me as I have run benchmarks with my HD3850 AGP then 7800GS on the same hardware.

The HD3850 should beat the 7800 in 3dmark2001 and 2003 and so on. chances the driver overhead is a lot bigger for the 3850, it needs a more powerful cpu to push it.
Another possibility is the driver is simply not optimised for running ancient dx6 or dx7 benchmarks.

On Super socket 7 You will get higher scores in 3dmark2000 with a gf2 or gf3 than a ti4200 or faster card.

Actually I got 30+fps more in doom3 with 7800gs than Hd3850, 130fps vs 96fps that was with overclocked Pentium M on Asus socket 478.

Hi Imperious,

Bizzare! Well I might as well drop it from my list of benchmarks then!

Hello

Win98se
Tualeron 1200 @ 1600mhz
Asus Tusl2-c 1.04
512mb pc133 2-2-2-5

800×600, 16bit

Asus 9280 ti4200 64mb @ 300/600
3dmarks: 10788
CpuMark: 21444

2 × Diamond Monster II 8mb @ sli
3dmarks: 4642
CpuMark: 21259

Br

stereotyp wrote on 2022-10-20, 20:10:

Hello […]
Show full quote

Hello

Win98se
Tualeron 1200 @ 1600mhz
Asus Tusl2-c 1.04
512mb pc133 2-2-2-5

800×600, 16bit

Asus 9280 ti4200 64mb @ 300/600
3dmarks: 10788
CpuMark: 21444

2 × Diamond Monster II 8mb @ sli
3dmarks: 4642
CpuMark: 21259

Br

What is your SL spec for this tualatin celeron 1200 overclocked to 1600?

Thanks and cheers,

stereotyp wrote on 2022-10-20, 20:10:

Hello […]
Show full quote

Hello

Win98se
Tualeron 1200 @ 1600mhz
Asus Tusl2-c 1.04
512mb pc133 2-2-2-5

800×600, 16bit

Asus 9280 ti4200 64mb @ 300/600
3dmarks: 10788
CpuMark: 21444

2 × Diamond Monster II 8mb @ sli
3dmarks: 4642
CpuMark: 21259

Br

I was blown away when I noticed that Tualatin-P3 is so much faster than Tualatin-celeron. I recommend to get a cheap 1266MHz Tualatin-P3 with 512Kb cache and overclock it to over 1500MHz, it'll destroy Tualeron.

I actually prefer Tualeron for this particular setup (sure, i already have oc'ed Tualatin P3's in other p3 systems), because it is somehow underdog but still, it works on 1600mhz which is cool. Besides, i wanted to go with max 133 fsb on TUSL2-C since i don't want my V2 sli to work on oc'ed PCI and i can run my RAM on 2t.

Is there something else requried to get 3D Mark 99 max running on Windows 95? Im on Win 95 4.0 Build 1111 C, MMX 233Mhz, Direct X 7.0, S3 Virge DX and Voodoo 1

When I launch 3D Mark, I get a black screen for a second or so then it exists to the desktop

Thanks

edit - ignore, found my answer - 3D Mark 99 Max & 2001 SE Startup Hang Patch

smeezekitty wrote on 2014-07-09, 06:25:

Record low?
...
486DX-120 + S3 ViRGE

I got a bit more:

3D Mark 99 Max on a 486 under Windows 2000
(Patch by mkarcher: poor Direct X version detection removed)
Graphics: Matrox G450 PCI
CPU: Am5x86 @ 160 MHz
RAM: 256 MB
L2: 1024 KB

Rendering Platform Matrox Millennium G450 Dual Head DVI PCI - Deutsch
Resolution 800*600
Color Depth 16-bit Color
Frame Buffer Triple buffering
Refresh Rate 73 Hz
CPU Optimization Intel(r) processor
3DMark Result 14,77 3DMarks
Synthetic CPU 3D Speed 4,80 CPU 3DMarks
Rasterizer Score 25,07 3DRasterMarks
Game 1 - Race 0,15 FPS
Game 2 - First Person 0,14 FPS
Fill Rate 2,36 MTexels/s
Fill Rate With Multi-Texturing 2,61 MTexels/s
2MB Texture Rendering Speed 2,09 FPS
4MB Texture Rendering Speed 2,04 FPS
8MB Texture Rendering Speed 2,05 FPS
16MB Texture Rendering Speed 1,28 FPS
32MB Texture Rendering Speed 0,07 FPS
Bump Mapping Emboss, 3-pass 0,97 FPS
Bump Mapping Emboss, 2-pass 0,98 FPS
Bump Mapping Emboss, 1-pass 1,24 FPS
Point Sample Texture Filtering Speed 100,56 %
Bilinear Texture Filtering Speed 100,00 %
Trilinear Texture Filtering Speed 83,39 %
Anisotropic Texture Filtering Speed 0,00 %
6 Pixel/individual 2,76 KPolygons/s
6 Pixel/strips 2,94 KPolygons/s
25 Pixel/individual 3,03 KPolygons/s
25 Pixel/strips 2,63 KPolygons/s
50 Pixel/individual 3,05 KPolygons/s
50 Pixel/strips 2,48 KPolygons/s
250 Pixel/individual 1,57 KPolygons/s
250 Pixel/strips 0,48 KPolygons/s
1000 Pixel/individual 0,27 KPolygons/s
1000 Pixel/strips 0,12 KPolygons/s
Processor Type AMD 486/5x86WB
Processor Speed 160 MHz
L1 Cache size 16 KB
L2 Cache size 1024 KB
Physical Memory 256 MB

Resolution 640x480 1024x768
Colour Depth 16-bit Color "
Frame Buffer Triple buffering "
Refresh Rate 73 Hz "
CPU Optimization Intel(r) processor "
3DMark Result 15 3DMarks "
Synthetic CPU 3D Speed 5 CPU 3DMarks "
Rasterizer Score 14 3DRasterMarks 24 3DRasterMarks
Game 1 - Race 0,2 FPS "
Game 2 - First Person 0,1 FPS "
Fill Rate 1,2 MTexels/s 2,7 MTexel/s
FillRate With Multi-Texturing 1,2 MTexels/s 2,5 MTexel/s
2MB Texture Rendering Speed 2,0 FPS 1,8 FPS
4MB Texture Rendering Speed 1,5 FPS 2,0 FPS
8MB Texture Rendering Speed 1,9 FPS 1,3 FPS
16MB Texture Rendering Speed 1,3 FPS "
32MB Texture Rendering Speed 0,1 FPS "
Bump Mapping Emboss, 3-pass 1,0 FPS 0,9 FPS
Bump Mapping Emboss, 2-pass 1,0 FPS "
Bump Mapping Emboss, 1-pass 1,3 FPS 1,2 FPS
Point Sample Texture Filtering Speed 127,9 % 100,4 %
Bilineat Texture Filtering Speed 100,0 % "
Trilinear Texture Filtering Speed 96,2 % 93,9 %
Anisotropic Texture Filtering Speed Not Supported "
6 Pixel/individual 3,1 KPolygons/s "
6 Pixel/strips 3,0 KPolygons/s 2,7 KPolygons/s
25 Pixel/individual 2,8 KPolygons/s 3,0 KPolygons/s
25 Pixel/strips 2,8 KPolygons/s "
50 Pixel/individual 3,1 KPolygons/s "
50 Pixel/strips 2,5 KPolygons/s 2,3 KPolygons/s
250 Pixel/individual 0,8 KPolygons/s 2,9 KPolygons/s
250 Pixel/strips 0,3 KPolygons/s 1,0 KPolygons/s
1000 Pixel/individual 0,2 KPolygons/s 0,5 KPolygons/s
1000 Pixel/strips 0,1 KPolygons/s 0,2 KPolygons/s
Missing features

Image quality: All pictures looking good.

Just ran this on my "Ultimate late '98 system"

Pentium II 450
256Mb 100Mhz SDRAM
Diamond Viper V550 (nVidia Riva TNT)
Windows 98SE

I think it did alright

3D Mark 99 Max will deliver wrong results on CPUs without RDTSC command.
mkarcher is examining this issue.

Related CPUs: All 486, Cyrix 6x86

Oh, what a wonder:
Now we have 281 3DMarks and 359 CPU 3DMarks.
Graphics card is a GeForce 5200 PCI with 256 MB RAM, not the Matrox.

The file RLMFC.DLL needs to be patched.
The values still are not exact yet, because a debugger was active.

Without debugger:
285 3DMarks with 362 CPU 3DMarks. 486/133 with GeForce 5200 PCI 256 MB VRAM.
240 3DMarks with 352 CPU 3DMarks. 486/133 with Matrox G450 PCI 32 MB VRAM.

Edit: Oops. That were the values for 133 MHz.
The values for 160 MHz will follow very soon 😀
289 3DMarks with 447 CPU 3DMarks. 486/160 with Matrox G450 PCI 32 MB VRAM.
Error on GeForce 5200 at 40 MHz PCI clock.

Has anyone been able to get it to work in W10? I'm getting an error even with 3DMark_99_max_fix.zip. Compat mode doesn't work.
Edit: got it to work with the ddraw file from dgvoodoo2, however the framerate is locked at 60 and I can't find a way to unlock it. Vsync is off already.

Edit2: was able to disable vync with elishacloud's dxwrapper, DDrawCompat = 1. Although it still seems to get locked to 60 for a couple of seconds in a few places.
3570k@4.4ghz & 1060 gtx 6 gb.
Getting very different results depending on which CPU optimization is selected:

This post discusses 3DMark 99 Max, as you can currently download from Futuremark for free.

Let's start with a disclaimer. 3DMark 99 is specified to require a 166MHz Pentium Processor, and support for Windows 2000 is explicitly denied. This post about running 3DMark 99 on a 486-class processor on Windows 2000 thus is oprating 3DMark 99 well outside of the specified operating conditions.

It's widely known that 3DMark 99 doesn't start on Windows 2000 unless you remove the DirectX version check (which is programmed in a way that it fails to work with Microsoft's DLL versioning scheme used for DirectX on Windows NT) or run it in Windows 98 compatibility mode. Windows 98 Compatibility Mode includes a shim called "DxVersionLie" that reports the DirectX DLL file version numbers as the same DirectX version for Windows 98 would have. Furthermore, the Anti-Lockup patch is required to 3DMark 99 to start on NT-series windows. The remaining parts of the post assume that these known issues already have been dealt with.

3DMark 99 tries to use RDTSC (read timestamp counter, which is supposed to return the number of processor clocks since power-up) for precision timing. It properly detects whether the processor supports it. If the processor does not support it, 3DMark 99 falls back into a mode called "Cyrix mode" according to the name of the exported function of RLMFC.DLL. This is likely due to the fact, that the Cyrix 6x86 processor didn't support RDTSC.

Interestingly, the lowest level abstraction has these methods:

1. get the current time as 64-bit value (of unspecified format)
2. calculate the difference between two 64-bit timestamps returned from method 1, returning a 64-bit difference (again of unspecified format)
3. convert a difference returned from method 2 into a floating point value containing the number of "cycles". Here the format is specified.
4. get the clock speed in "cycles" per second.

In RDTSC mode, the timestamp and the timestamp difference are 64-bit integers, and the cycles per second are the actual processor clock (assuming that there is no such thing as SpeedStep). The processor clock is determined by timing a loop that polls the wall-time clock to advance by 0.5 seconds.

In Cyrix mode, 3DMark 99 falls back to reading a processor speed independent time value, and converts it to seconds since program start stored as 64-bit double precision floating point number. The difference is again a 64-bit floating point number, and the "convert difference to floating point number" function just returns its parameter. The processor clock is reported as "1 cycle per second", so the timing values in seconds used here can be treated as virtual processor clocks, too.

This could be all to it, and it could work perfectly with a shared common code path above it. Too bad it is not implemented that way. The next layer above also distinguishes between processors with and without RDTSC. The code path for processors without RDTSC fails to initialize a variable that is supposed the frame time in seconds. Too bad that this variable is used for all the score calculations in 3DMark. This can quite easily be worked around by just removing the no-TSC case from the higher level code. The result is: You get scores, but more often than not, Result Browser locks up when you try to load the project file with the detailed benchmark values. This turns out to be due to the "2MB Texture Rendering Speed" being measured as infinite frames per second, and being processed in a way that an intermediate result contains NaN (not a number). The code that processes these intermediate results can't deal with the special behaviour of NaN values in comparisons, and enters an endless loop.

So another patch is needed. The Cyrix mode uses a generic function "getAppAge" to retrieve the wall-clock time since the start of 3DMark 99. This function is implemented on top of the WINMM function timeGetTime. On Windows 95, this function returns the time since boot in milliseconds (and that value overflows after 49 days), on later Windows version, a certain offset is added to it so it overflows the first quickly after power-up. This has been implemented to detect problems caused by not dealing with overflow of this value, which caused the infamous "Windows 95 locks up after 49.5 days without crashing" issue. While the unit of the timestamp is milliseconds, it doesn't mean we get millisecond resolution, even more so on Windows NT (and descendants). The "time counter" returned by timeGetTime is incremented by several ms every timer tick interrupt. To conserve processing power, Windows NT runs the timer at 100Hz, incrementing the time counter by ten milliseconds on each interrupt. You can request a higher precision of the timeGetTime counter using timeBeginPeriod and timeEndPeriod, up to 500Hz or even 1000Hz, but 3DMark 99 doesn't do so. This means that timeGetTime, while being fast, as it just reads one global kernel variable, can return the exact same value on begin and end of a frame, if the frame takes less than 10ms to render. (On Windows 95/98, the default rate of the timer is claimed to be around 300 to 500 Hz, so the issue is not that prominent there) If the begin time is equal to the end time, the frame duration is 0ms, and thus the frate is INF fps. While 3DMark uses a 16-frame moving average over 16 frames to calculate the resulting frame rate, as soon as one frame in that window is determined to run at INF fps, the average of the 16 fps values is also INF fps (yeah, that's again broken, as you should average over frame times, not over frame rates, but as long as the samples are close to each other, the difference is negligible). So what's required is a time source with higher precision. While you can increase the timer frequency using timeBeginPeriod, the increased timer frequency will take some CPU cycles for no actual gain. There is a different solution, though: The Win32 API contains the functions QueryPerformanceCounter and QueryPerformanceFrequency. These functions do not just read a value updated each timer interrupt, but they ask the timer chip for the time since the last interrupt as well as fetching the timestamp of the last timer interrupt, so you get around microsecond resolution using them. The disadvantage of QueryPerformanceCounter ist that it might be considerably slower than timeGetTime. As 3DMark only calls this function twice per frame, this disadvantage is irrelevant, though.

Please find attached a patched version of rlfmc.dll that unifies the TSC and non-TSC code paths as much as possible, and switches non-TSC timing from timeGetTime to QueryPerformanceCounter. I validated it as well as possible to work correctly on non-TSC machines and still work as before on TSC-capable machines.

Awesome work mkarcher!

11784 3dmarks with a voodoo 5 5500.

4coredual-sata 2 with C2D E7500

mkarcher wrote on 2023-02-06, 21:43:

Please find attached a patched version of rlfmc.dll that unifies the TSC and non-TSC code paths as much as possible, and switches non-TSC timing from timeGetTime to QueryPerformanceCounter. I validated it as well as possible to work correctly on non-TSC machines and still work as before on TSC-capable machines.

Thanks a lot. Finally a patch that counts FPS. Until this one i always had like 0 to 1 fps counts during the benchmark. Although the results are way lower than they are on windows xp and windows 7
I've attached a screenshot with 33mark99 results from left to right: Windows XP + 10900k @ 5700mhz CPU (6 cores active no HT) , Windows 10 + 13900 @ 6300mhz (6 P cores no E cores no HT), Windows 7 + 10900k @ 5700mhz (6 cores active no HT) .
Although 13900k at 6300mhz is much more powerfull than 10900k at 5700mhz, the FPS is much lower. I would love to try 13900k with Windows 7, but there's no VGA driver for RTX 4090 and Windows 7.

Aurosonic wrote on 2023-03-01, 00:11:

Thanks a lot. Finally a patch that counts FPS. Until this one i always had like 0 to 1 fps counts during the benchmark. Although the results are way lower than they are on windows xp and windows 7
I've attached a screenshot with 33mark99 results from left to right: Windows XP + 10900k @ 5700mhz CPU (6 cores active no HT) , Windows 10 + 13900 @ 6300mhz (6 P cores no E cores no HT), Windows 7 + 10900k @ 5700mhz (6 cores active no HT) .
Although 13900k at 6300mhz is much more powerfull than 10900k at 5700mhz, the FPS is much lower. I would love to try 13900k with Windows 7, but there's no VGA driver for RTX 4090 and Windows 7.

Yes, that's a different issue. If you look at "CPU optimization", it says "Intel Processor" with the 13900K.
However, with the 10900K on Windows XP & 7, it says "Intel Pentium III". This most likely means that it's unable to detect and properly use the SSE instructions with the 13900K, which is also the case with many other modern (and not so modern) CPUs. I don't think it's OS related, because this also happens on Windows 98 with certain CPUs like the VIA C3 Nehemiah.

PS: awesome work, @mkarcher! 😀

Athlon XP (Barton) 2.13Ghz, 256MB SDRAM
Windows 98SE DirectX 6 (need an early driver for DX6)
Voodoo3 2000 - default clock, default 3DMark99 template (800x600, etc...)

Result:
6291 3DMarks
32288 CPU 3DMarks

Looks right for this card. the V3 3K seems to score a couple hundred points higher from other posts in this thread.