My guess is that 32 bit vs 64 bit code would not make a difference if computation is done with SIMD or anything except 64 bit integers. So 32 bit code might be faster, more so on Core 2 which doesn't benefit from macro-fusion in 64 bit.

Also, a pixel pipe contains many operations that are fully pipelined on a Voodoo, which is not the case with CPU emulation so you can't finish one or a multiple of pixels every cycle.

Edit: I forgot a non negligible advantage of 64 bit code, which is double the architectural registers (general and SIMD), but register renaming may help use all the internal registers anyway in 32 bit.

64bit has more general purpose registers.
It is practically always faster than 32.

SSE is a 128bit wide integer unit which can run 16x8bit integer operations simultaneously.
https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

Assuming you're working on pairs of RGBA, that means 8 operations, or 2 pixels simultaneously in theory.
Eg, R1+R2, G1+G2, B1+B2, A1+A2, R3+R4, G3+G4, B3+B4, A3+A4

It would depend on the operation, of course, but for a simple addition that is basically how it works.

AVX is similar, but floating point.
It's "wasteful" to work on effectively 8 bit numbers, but with eight 32-bit single-precision floating-point numbers, you effectively repeat the above.
Eg, R1+R2, G1+G2, B1+B2, A1+A2, R3+R4, G3+G4, B3+B4, A3+A4

So if you use both units, you could have a 2 stage "pipeline" in whatever order makes the most sense given converting int > float is implied.

Possibly the FBI is one and TMU the other?

We're talking 2+ghz cpus capable of 16 simultaneous operations trying to emulate a tiny little 50mhz ASIC here. I can't imagine it's not possible to do the equivalent of an SLI voodoo2 comfortably on one core IF the memory can be fetched/cached properly, and both SSE and AVX are pumping.

There has to be a way to break the workload into chunks that suit a CPU's cache/memory architecture.
By function? TMI/FBU =AVX/SSE?
By colour? R first, G, B, then alpha?

I just found that Glidulator can run on multiple cores under Crazii's VDPMI (I though it's impossible in V86 mode at general).
So I could get it running with SBEMU VDPMI version. And it runs fine with Tomb Raider (using PC No-CD 😀 Rendering seems to be capped at 30FPS @640x480 accodring to HUD info, it's playable smoothly...

Feel like trying out Descent II or Carmageddon? Apparently they're "intensive" and not frame capped.
NFI if it's true or slopscination

What CPU?

I think you are both right: Glidulator doesn't depend on the OS running on CPU0, and the other cores act just like microcontrollers. But 64-bit is not the holy grail, even if it shines from a distance. The Voodoo doesn't calculate with 8 bits but with 12.12 fixed-point, and Z is even 20.12. So you need 16- or 32-bit lanes, which means 4-8 pixels per vector. And as ockiller stated, the Voodoo does many things in parallel within a single clock, which takes a CPU roughly 50-200 clocks per pixel (according to Claude). Or, to look at it from another angle: for 90 MPix/s on a single 3.4 GHz core, there are only about 38 clocks left per pixel. Also, the Voodoo1 processes only about 1 pixel per clock, and the Voodoo2 only adds a second TMU for a second texture in the same pass. SLI is not relevant here, since Glidulator already spreads the load across multiple cores in an SLI'isch way (it turned out that grouping lines into blocks is much more efficient than interleaving single lines).

Also, SSE and AVX use the same ports and registers, so using them "in parallel" is not possible. Instead, mixing legacy SSE and AVX code causes heavy transition penalties, especially on Haswell (which is a very nice target for this software). Cache misses are not the problem: the cache should be big enough to hold the textures, and spans are written sequentially. The real costs are the branches for the many render modes, plus texture fetches with filtering and the perspective division.

I will try winsimd, it looks quite promising. But if SIMD math is not the bottleneck, the renderer won't benefit much from it anyway. So 64-bit and AVX would work on the worker cores, but I think the gains are elsewhere

Tell us more about the branches.
And which are the hottest functions in the code?

RayeR wrote on Today, 04:44:

I just found that Glidulator can run on multiple cores under Crazii's VDPMI (I though it's impossible in V86 mode at general).
So I could get it running with SBEMU VDPMI version. And it runs fine with Tomb Raider (using PC No-CD 😀 Rendering seems to be capped at 30FPS @640x480 accodring to HUD info, it's playable smoothly...

I`m very happy to hear that 😀.

myne wrote on Today, 07:24:

Feel like trying out Descent II or Carmageddon? Apparently they're "intensive" and not frame capped.
NFI if it's true or slopscination

What CPU?

For Descent II you have to use D2_3DFX, but I haven't tested that yet.

A sidenote: I tried to replace the ddraw.dll to support early DX5-6 titles, but this turns out to be very difficult. I'm thinking to maaaaybe do that for some very specific titles like FF7 or games which have issues with table fog. But I think the best solution is a driver like velocity9x, which does the proper rendering at the right place.

myne wrote on Today, 10:27:

Tell us more about the branches.
And which are the hottest functions in the code?

I'll get to that, but first I have to play NFS 5 😁. It seems to run fine, but table fog is missing. I need to test more titles before I can say whether it's worthwhile to support Glide3.

myne wrote on Today, 07:24:

Feel like trying out Descent II or Carmageddon? Apparently they're "intensive" and not frame capped.
NFI if it's true or slopscination

What CPU?

I thought Glidulator won't work in DOS Tomb Raider or Carmageddon. Has this changed since the release of 0.9.1?

And in Screamer 2 and Screamer Rally 3DFX DOS .exe's, I get 50-60fps on an i7-8600 with MTRRs enabled. With 2x antialsing and the screen AR set to 4:3 centered on the native 1920x1080 display, this drops to 30 fps. All 4 cores are active.

I got about 190-210 fps in 800x600 on RayeR's test30 program posted above. With MTRRs enabled, same system @ 4.2 Ghz.

The difference between disabling MTRRs and enabling them is massive... at least 400-500% faster with MTRRs enabled! Unplayable without MTRR write-cache combining in LFB.

That's more like it.
I was under the impression it was struggling to hit 60.
All good then.
Prune the branches back and it'll be comfortable on one core as it should be.
And 64 bit has another advantage. You can reserve above 4gb and never worry about conflicts.

ElTentakel this might be of some interest to you.
https://github.com/nand2mario/zSST linked in the post I linked a few pages ago.

Well, I ran it through verilator.
https://verilator.org/
After more than a few fails, I got source with the following command:

1..\verilator -Wno-WIDTHEXPAND -Wno-WIDTHtrunc -cc .\sst1_pkg.sv .\generated\sst1_regs_pkg.sv .\generated\sst1_tmu_tables_pkg.sv .\frontend\sst1_addr_decode.sv .\frontend\sst1_float_to_fixed.sv .\frontend\sst1_pci_fifo.sv .\frontend\sst1_regfile.sv .\frontend\sst1_frontend.sv .\tmu\sst1_texture_layout.sv .\tmu\sst1_tmu_front_staged.sv .\tmu\sst1_texture_cache_ram.sv .\tmu\sst1_texture_cache.sv .\tmu\sst1_texture_address.sv .\tmu\sst1_texel_decode.sv .\tmu\sst1_texture_combine.sv .\tmu\sst1_tmu.sv .\fbi\sst1_pixel_pipeline.sv .\fbi\sst1_fb_write_combine.sv .\fbi\sst1_fb_read_cache.sv .\fbi\sst1_fbi.sv .\video\sst1_video_control.sv .\sst1_perf_counters.sv .\sst1_core.sv .\sst1_device.sv

-Wno-WIDTHEXPAND -Wno-WIDTHtrunc ignore word size changes. -cc outputs to c++