javispedro1 wrote on 2023-01-30, 00:34:. I think that one of the main pros of (2D/GDI) hardware acceleration would be in emulation, where e.g. the native Windows rende […]
Show full quote
Jo22 wrote on 2023-01-29, 22:06:
Personally, this worries me a bit. The statement is a bit hollow, I think.
The specs of the test system are not just vague, but unknown, even.
. I think that one of the main pros of (2D/GDI) hardware acceleration would be in emulation, where e.g. the native Windows rendering code
would be run under the emulator while the rendering code from the emulated card would be run in the host.
From the point of view of virtualization, where there is little if any difference in performance between guest code
and host code (any performance issues come from other aspects, like VM exits / IO), I don't see the point.
Yes, that would be neat, I think, too.
Things like this were being done in the early 90s, too, in one way or another.
For example, Insignia SoftWindows 1.0, the Windows 3.1+PC emulator for the 68k Macintosh,
used special libraries of Windows 3.1 that were ported to the Motorola 68000.
This was possible because Insignia worked closely together with Microsoft.
The company also provided the x86 emulator for the NTVDM used in the RISC versions of Windows NT.
Anyway, the idea was similar.
The Windows applications would call DLLs/their functions that would execute naively on the host side.
Maybe GDI was part of it, even, not sure.
That's something special in emulation, by the way.
Graphical systems provide function calls, APIs.
An emulator of such systems doesn't need to perform as much as CPU-intensive tasks
as an low-level emulator meant for DOS programs which like do talk to hardware directly and do implement their own logic.
Anyway, I'm not blaming DOS. DOS itself had an ABI/API that works similar, yet different.
It provided functions via interrupts, rather than conventional API calls as used in normal operating systems.
Unfortunately, the calls provided weren't enough. There was no graphics/sound ABI/API, for example.
DOS programmers were expected to use PC BIOS (has routines for CGA graphics) or EGA/VGA BIOS for this.
Or the high-level interface of 8514/A or XGA/XGA-2, which sadly didn't make it.
CP/M had gotten GLX in its late days, by comparison. 😁
Edit: GDI.. GDI was quite flexible as far as the range of supported hardware was considered.
It could be used for printers/plotters, too, most notably. Or remote desktop connections.
It kind of reminds me of X11 in this regards, another great obsolete technology.
Back in the late 90s, early 2000, XFree86 was a thing, still.
Edit: GDI+, as used by Windows XP+ (or Windows 9x by gdiplus.dll), was entirely CPU-based.
Applications relying on it can't take advantage of GDI acceleration, not even in Windows XP/7.
javispedro1 wrote on 2023-01-30, 00:34:I am surprised because I always hear these tools mentioned, but I never needed to resort to 3rd party tools to avoid high CPU ut […]
Show full quote
Jo22 wrote on 2023-01-29, 22:06:
Edit: CPU utilization is a general problem in DOS-based systems.
For 9x, there's amnhlt, a little helper VXD that puts the CPU to sleep.
Re: 86box produces farting noises and lags on an i7 PC
I am surprised because I always hear these tools mentioned, but I never needed to resort to 3rd party tools to avoid high CPU utilization.
VirtualBox supports both ACPI and APM, the later being supported as early as Windows 3.x at least.
Even on DOS 6.x, I can use POWER.EXE to reduce CPU utilization to 0. From the documentation, it looks like it is also an APM driver.
Personally, I had to resort to those 3rd party tools.
For some reason I don't know, the CPU would see a high utilization without them. 🤷♂️
I'm aware of APM and ACPI, as well. Unfortunately they don't seem to be reliable.
Maybe because they're meant to save power rather than lower CPU usage, so the results aren't as expected.
Especially ACPI used to have compatibility issues in the 90s, I think.
Older revisions were broken and didn't work with Linux, which tried to follow the official specs.
Windows 98 had some workarounds for it, I vaguely remember,
but it wasn't before Windows Me/2k (roughly) that ACPI worked reliable.
APM and the 386SL CPU with SMM/power-savings features existed since the early 90s.
HLT is implemented in late 486 desktop CPUs, too, I think.
Windows 3.1x also supports APM. On paper, at least. Never really worked in my VMs, either.
Here I'm using WQGHLT, which unfortunately but understandably was written for 386 Enhanced-Mode.
The rock-solid Standard-Mode isn't supported by it.
The Power.exe in DOS merely talks to APM BIOS, which in turn has to take actions.
APM is/was very BIOS-centric in comparison to ACPI. The BIOS decided when to do things.
Programs like DOSIDLE have many options and also support APM.
That's what I use in DOS VMs, also. Just be careful not to set it too strong.
Certain programs with idle loops woukd otherwise halt completely (need keyboard press to run again etc). 🙂
Edit: Edited, some typos fixes.
Edit: Formatting fixed (on PC).
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//