JHRobotics
commented
1 year ago Hello, main problem with requirement of SSE was problematic CRT (C runtime) in MSYS MinGW distribution, which was compiled with SSE instructions, so they were inserted to code regardless on “-march” flag. Version 17.x I was able to compile with older complier but newer no (C++14 is required).
However I found working MinGW distribution (from here: https://github.com/niXman/mingw-builds-binaries/releases/tag/13.1.0-rt_v11-rev1) without this behaviour – so in last release the “Windows 95” binaries are without SSE instructions in runtime, but LLVMpipe is still able to use SSE instructions, if they are present.
I appreciate the effort to get some additional graphics acceleration options into DOSBox, but I'm not entirely sure if VMWare SVGA is the way to go. The problem with this is that quite a lot of calculations are done in the guest system, and in the newer version of the protocol (GPU gen. 10 or SVGA-III), for example, all the surfaces (textures, framebuffer, and other work buffers) and graphics structures are stored normally in RAM (that are on the real HW located in VRAM). Of course, this has its own logic - if you run multiple virtual machines, you must try to allocate resources as efficiently as possible, and if all things are in memory in the guest system, you have no hidden overhead, and you can also inflate the allocated RAM (memory ballooning) according to how much you really need and you don't have dead textures somewhere in the host memory.
But in the emulator, on the contrary, you have to try to compute as few things as possible in it. Because even with dynamic recompiler, emulation is very, very slow compared to native code. Therefore, it seems to me that a much better way is using shared memory for surfaces (textures, framebuffer, ... = the guest needs to write and read its data) and with addition some FIFO queue, where guest API calls will be pushed.
3D acceleration which is done in this way, for example here: https://github.com/kjliew/qemu-3dfx and basically also in DOSBox when GLIDE is emulated (the entire HW is not emulated, but individual calls are then passed to the library in the host system). It only has the problem, that a driver has to be written for it, which is not entirely easy in the case of Windows 9x, but it still seems easier to me than either optimizing a complex driver to be faster in the emulator or emulating a real (and mostly poorly documented) graphic HW.
Speaking of DOSBox, it should also be mentioned, that some S3 Trio and especially S3 Virge are capable of 3D acceleration - although the DDI version is only 5.0 (DirectX 7 maximum) and the real HW was so slow that it was nicknamed “decelerator”, in theory can work in the emulator better. In addition, there is a driver including source code (part of DDK98).
Sorry that my answer has a lot of letters, but even in virtual machine the performance of the driver depends a lot on the performance of the CPU itself (e.g. Intel i7 4th gen. + GTX 1650 vs. AMD Ryzen 5, 3th generation, or Intel i5 11th gen. + integrated GPU wins the newer CPU by quite a lot, regardless of the graphics card used). And I have a feeling that my driver will be really very slow in the emulator.
But I don’t want to only be saying "won't work", I'll try to follow the development of the implementation and, if I'm able, I'll try to contribute some code.
Torinde
joncampbell123
DOSbox-X supports Win9x, so it would greatly benefit from SoftGPU 3D accelerated driver.
What will be needed to achieve that?
DOSbox Pure is anothe DOSbox fork that officially supports Win9x. 86Box "Virtual PC" machine and related emulators would benefit from support as well. 86Box discussion dosemu2 discussion