RayeR wrote on 2026-10-14, 00:33:

But I'm not sure if every CPU core has it's own set of AVX regs or they are common per CPU package...

They are per core, same as general purpose registers, i.e. even "fake" hyperthread cores have their own.

I don't have any DOS 3Dfx game handy to test so I tried just with test30 (included below) from GLIDE SDK.
Core i7-2600K @4,.5GHz, MTRR enabled, voodoo mode 800x600, vsync=0
I got ~150 FPS under plain MSDOS 6.22 (HIMEM only), 3 JIT threads
I got ~370 FPS under WinXP (win32 version), 3 JIT threads
I heard how my CPU fan spinning up so it was really working hard 😀

BTW would Tombrider1 work with TUMBRUSH.EXE patch? This one is dynamic-linked. I have downloaded TR demo only that doesn't work, probably need a full version of the game...

jmarsh wrote on 2026-10-14, 01:54:

They are per core, same as general purpose registers, i.e. even "fake" hyperthread cores have their own.

OK, maybe I confused this with some reading that physical AVX execution unit in the CPU is only one or less units than cores but it could have separate set of registers per core...

RayeR wrote on 2026-10-14, 03:26:

OK, maybe I confused this with some reading that physical AVX execution unit in the CPU is only one or less units than cores but it could have separate set of registers per core...

They're extensions of the regular SSE registers. Lower half of the ZMM registers (512 bit) are the YMM registers (256 bit), and the lower half of those are the (original 128-bit SSE) XMM registers.
I'm not really sure what the current "state of play" is with regards to which CPUs support which instruction sets; it got very confusing because Intel introduced AVX-512, then abandoned it due it being problematic with mixed high-performance/low power cores, then it became relevant again because AMD finally got around to implementing it in their current offerings...

RayeR wrote on 2026-10-14, 00:33:

BTW one last retro project still missing - need some (at least basic 2D) accelerated driver for newer nvidia GPU like GTX-9xx family for win9x and NT4, let someone kick AI ass to port nouveau driver from Linux 😀

While cool, I personally don't think there's much need.
The most common GPU in the world is the Intel igpu.
I did the sums, and basically Sandybridge should comfortably beat the 6800.

Some points:
* 6800 being the highest supported 9x gpu, implies that every 9x ONLY game should run well.
(please dont "Akchually the 6850ultramaxmax or quadro or 7950 blah blah can be made to work with duct tape and a screw driver" Not the point.)
* Performance beyond that while not a problem really only becomes higher levels of overkill.
* XP games that can run on 9x are in that grey zone, but I'd argue that if they CAN run on XP, they should. Therefore there's no need to bother with making 9x better for them. Albeit there are millions of dirt cheap 8000/9000s.

IF I was the one in charge of prioritising:
1) Intel IGPU
2) AMD GCN/IGPU (surprising amount of SOC systems)
That would in practical terms cover 99% of any possible "I want to build a 9x box" needs.
3) Everything else. But there will be staggeringly few people out there unable to work with those options.

I'm not in charge. It's not my project.
It's also kinda the wrong thread 😒

RayeR wrote on 2026-10-14, 03:26:

I don't have any DOS 3Dfx game handy to test so I tried just with test30 (included below) from GLIDE SDK. Core i7-2600K @4,.5GHz […]
Show full quote

I don't have any DOS 3Dfx game handy to test so I tried just with test30 (included below) from GLIDE SDK.
Core i7-2600K @4,.5GHz, MTRR enabled, voodoo mode 800x600, vsync=0
I got ~150 FPS under plain MSDOS 6.22 (HIMEM only), 3 JIT threads
I got ~370 FPS under WinXP (win32 version), 3 JIT threads
I heard how my CPU fan spinning up so it was really working hard 😀

BTW would Tombrider1 work with TUMBRUSH.EXE patch? This one is dynamic-linked. I have downloaded TR demo only that doesn't work, probably need a full version of the game...

Yes, it does, but I still have to add a proper device check not only for Voodoo Rush (SST-96) cards.

Did you run it with TB1 full version? I tried only demo and it crashed with TUMBRUSH.EXE

EDIT: it crashed due to HIMEM, may be too much XMS. Without HIMEM it didn't crash but TUMBRUSH.EXE asked for original game CD insertion, damn...

Yes, unfortunately it's true that games crash under DOS with HIMEM.SYS when there's too much memory. Even after a lot of testing, I haven't managed to work around it. I want to tackle that again once I have a better understanding of how HIMEM.SYS and the DOS extender interact.

Regarding the question about core usage: in multi-core mode, 1–3 cores are used, and the DOS core then doesn't do any rendering. More cores might be possible, but with too many, the load balancing becomes inefficient. There's certainly still room for optimization there, though.

Btw, I used the original german TR1 CD.

I also checked "Tomb Raider 1" on my system, and here’s what I noticed:

In Windows 98, it works fine in any configuration, but only one core is always available (JIT, Single Thread).

In MS‑DOS mode:

- in the "BURNMEM + HIMEM" configuration, before launching Windows: "JIT, Multi Thread";
- in the "BURNMEM + HIMEM" configuration, after logging out of Windows: "JIT, Single Thread";
- in the "BURNMEM + HIMEM + EMM386" configuration, before launching Windows: the game works, only the sound is output, but the image is not displayed (black screen);
- in the "BURNMEM + HIMEM + EMM386" configuration, after exit of Windows: the game works, but only the sound is output; the image is not displayed (black screen).

In the "SoftWare mode", in all the above‑mentioned options, the game works without any issues.

I also noticed that if "HyperThreading" is disabled in the BIOS, GLIDULATOR always works in "Single Thread" mode. Is this a bug or a feature?
It would also be good to test Core2 processors (x6800, qx6800 and similar), since, as far as I remember, they always have "HyperThreading" disabled (or it’s not available).*
* Explanation below.

Another question - how do you take a screenshot in GLIDULATOR?

Thanks a lot for the detailed testing, that's really helpful!

Memory managers (EMM386): This is expected behavior, and Glidulator probably won't support memory managers in the near future. EMM386 runs DOS in V86 mode with paging enabled, which prevents Glidulator from getting the low-level access it needs to start and control the additional CPU cores. In that case, it can't set up the render threads, so you get sound but no image.

After exiting Windows, it leaves the system in a modified state (paging is active), so a clean multi-core start is no longer possible afterwards. Please always boot straight into DOS (or use "Restart in MS-DOS mode") when you want multi-threaded rendering. Windows 98 itself only supports a single CPU, so "Single Thread" is expected there.

And regarding HyperThreading: This isn't intended. I think I've tested with HyperThreading both on and off, and multi-threading worked in both cases, so something else is probably going on. But I'll check again.

Glidulator doesn't have a built-in screenshot function. The screenshots I posted were taken with QEMU, which runs Glidulator very well and is also used for first tests.

ElTentakel wrote on Yesterday, 12:42:

And regarding HyperThreading: This isn't intended. I think I've tested with HyperThreading both on and off, and multi-threading worked in both cases, so something else is probably going on. But I'll check again.

Don’t bother, I checked everything myself and found the cause.

It turned out that GLIDULATOR shows the number of active threads as "n-1", where "n" = the number of active cores (with HT enabled, there are twice as many), and this is confusing in configurations with two active cores. In fact, 2 cores are used, but the statistics show "1 thread". With HT enabled, it shows "3 threads". The difference is noticeable in performance (FPS). I would suggest fixing this so that the statistics indicate the total number of cores, for example: "3\4 threads" or "1\2 thread" when HT is disabled. But this isn’t that critical.

What performance gain you got with HT enabled? I guess not so much. I have normally HT disabled for daily use in WinXP because enabled HT negatively affected singlethread apps and HT give me much less gain instead it would be physical cores. I only found HT usefull when compiling linux kernel with -j8 it was noticably faster than -j4 (about 20-25% if I remember...)

BTW to limit amount of available XMS is the best to use himemx.exe that has parameter for his...

Amazing!

You have not helped my project list at all though, now there's 3 extra machine configs I want to throw together with this in mind 🤣 Though actually it makes some of my last 2 years of random middle-aged hardware purchases seem like genius foresight.

Spent some time braining around why SSE2 might be needed, but I guess it's because the Voodoo chips are 64bit internally and faithful emulation will make use of 64bit float a lot, whereas with SSE1 it will take twice the clocks. However I am crossing my fingers that speed improvements in future will have it capable of "playable" on lower end duals at 640x480 and maybe fastish at 512x384 .... that's mostly a desire to bring it closer to late era hardware so other parts of system more authentic. Congratulations though, you've been the first person on planet earth to make a P4 Willamette look more attractive than a PIII-S Tualatin. 🤣

I don't think anyone ought to have high hopes of much reduction in price or increase in availability of genuine Voodoo hardware though. 20+ years of glide wrappers didn't hold it down, so don't think this will either. When reproductions, or standalone emulators, of nintendo etc consoles have been produced, the original hardware dipped briefly by about 20% then was flat for 6 months. But you know what happened? It made even more people crazier for the originals, and prices went skyward again. So give this a couple of months to get more viral around the further retro community, then another 3 for it to sink in, then you might have some voodoo hardware price relaxation, (But holy shit they doubled again since I last looked) that's your buy window, but it's still gonna be eyewatering. Then a few more months and whoops, more voodoo fans fighting over same limited supply.

I am guessing though, that as far as hardware to run this on is concerned, for demand/availability, it's a tradeoff, because genuine Voodoo performance scaling drops off quick at a ghz or so. Any quad seems to be potentially good in the end. As far as duals are concerned it might be good to allocate more main core timeslices above 2ghz or so. There's maybe some metric that can be figured for stealing main core cycles at thresholds that the game engine can't perform better per mhz, for want of more voodoo virtual clocks. Or have user selectable... lock main core at PIII-800 performance and let the rest voodoo kinda thing.

Anyway, lots of potential, excited for developments, thanks for taking this on.

RayeR wrote on Yesterday, 14:58:

What performance gain you got with HT enabled?

In the context of the same "Tomb Raider 1" under consideration, at the same save point (consistently reproducible results):

3 Core - HT = 30.3 FPS; RENDER: 32.5
2 Core + HT = 30.3 FPS; RENDER: 32.5
2 Core - HT = 20.0 FPS; RENDER: 49.3

Here, it’s important to note that in the case of "2 Core - HT", GLIDULATOR gets only one core. In the case of "2 Core + HT", it can already parallelize something, and in this case, as we can see, this is sufficient to achieve maximum performance (It’s obvious that the "30.3" ceiling here is artificial). The PoweVR version of the game supported 60 FPS, but unfortunately, the 3DFX version only supports 30 FPS max.

BitWrangler wrote on Yesterday, 14:59:

Spent some time braining around why SSE2 might be needed, but I guess it's because the Voodoo chips are 64bit internally and faithful emulation will make use of 64bit float a lot, whereas with SSE1 it will take twice the clocks.

Assuming the AI hasn't mangled my code too badly, the main SSE2 usage will be integer operations in the pixel pipeline code. SSE2 was used because when the code was written in 2016, it was a reasonable assumption that no one was still using a desktop CPU without it.

As far as I can tell, it's nearly identical: a few tweaks for Open Watcom, and the 32-bit JIT gets the LOD fix by calling the C path's calculation. Luckily it was written for SSE2, which made it easy for me. So thank you, without your work Glidulator wouldn't exist!

BitWrangler wrote on Yesterday, 14:59:

Amazing! […]
Show full quote

Amazing!

You have not helped my project list at all though, now there's 3 extra machine configs I want to throw together with this in mind 🤣 Though actually it makes some of my last 2 years of random middle-aged hardware purchases seem like genius foresight.
...
Anyway, lots of potential, excited for developments, thanks for taking this on.

Thank you very much! Maybe I can convince someone to port an RTOS to the worker cores and writes an HTTPS-to-HTTP proxy with a network stack on top of it. That would definitely make a lot of project lists longer 😁

DoZator wrote on Yesterday, 16:28:

The PoweVR version of the game supported 60 FPS, but unfortunately, the 3DFX version only supports 30 FPS max.

Thx for comparison. When I make TB working I can try on my i7 with and without HT, I gusess that in case of 4 phys.cores the difference would be smaller.

Why 30FPS limit for Glide? Is is specific for TB1 only? Could it be patched in binary or overriden in glide2x.ovl code? What highest resolution it supports?

ElTentakel wrote on Yesterday, 12:42:

Memory managers (EMM386): This is expected behavior, and Glidulator probably won't support memory managers in the near future. EMM386 runs DOS in V86 mode with paging enabled, which prevents Glidulator from getting the low-level access it needs to start and control the additional CPU cores. In that case, it can't set up the render threads, so you get sound but no image.

This depends on the specific game, because the black screen issue occurs in "Tomb Raider", but it doesn’t happen, for example, in "PYL Demo". The multithreaded configuration works normally with this game and the already loaded EMM386. Before playing, "HDPMI32I" is also launched; it stabilizes GLIDULATOR for this game in MS‑DOS mode and doesn’t interfere with later booting into Windows. In the GLIDULATOR settings, "paging" is selected accordingly. Available: 3\4 cores. It turns out that EMM386 itself is not an obstacle in this case for the operation of GLIDULATOR in a multi‑threaded configuration and for full image output. And yes, for this to work, "CPUID Limit" must be enabled in the BIOS.

ElTentakel wrote on Yesterday, 12:42:

After exiting Windows, it leaves the system in a modified state (paging is active), so a clean multi-core start is no longer possible afterwards. Please always boot straight into DOS (or use "Restart in MS-DOS mode") when you want multi-threaded rendering. Windows 98 itself only supports a single CPU, so "Single Thread" is expected there.

Regarding the modified states, there’s not much to add here for now, except that this state occurs at the earliest stage of loading, before the graphical interface is launched.

Can we, after exiting Windows (with WIN.COM unloaded), restore the system to its normal state so that GLIDULATOR can use multiple cores? Perhaps some registers need to be reset to their initial values (like after a cold start)?

The AI found out that Windows disables the APIC, so CPUID couldn't report it anymore. Paging was not the issue at this point. Also, in my VM CR0.TS stays set so every FNINIT in real mode runs in a loop, because the interrupt vector points to an empty BIOS IRET. I have to test it on real hardware later.

RayeR wrote on Yesterday, 19:28:

DoZator wrote on Yesterday, 16:28:

The PoweVR version of the game supported 60 FPS, but unfortunately, the 3DFX version only supports 30 FPS max.

Why 30FPS limit for Glide? Is is specific for TB1 only? Could it be patched in binary or overriden in glide2x.ovl code? What highest resolution it supports?

As far as I know, this is specific toTB1.