How do DOS games like DOOM benefit from a PCI graphics card?

Question

The original DOOM and its derivatives (DOOM II, Heretic, Hexen) were early 90s 3D games released at a time when DOS PCs usually had ISA bus Super VGA graphics cards. In the following few years, PCs would be upgraded to PCI bus graphics cards. The difference was stark, with PCI bus running at 33 MHz and 32-bits wide.

But DOOM engine games not only run fine on newer PCI graphics cards, but seem to benefit from the added performance. Anecdotally, DOOM on a Pentium PCI machine is faster than on an 80486DX with ISA graphics by a margin that suggest to me it isn't just a result of the marginally faster CPU. So, I am speculating that the PCI bus graphics card is also leveraged somehow.

How does DOOM (specifically) use this newer bus and graphics card than what it was written for to get added performance?

Answer 1

DOOM itself doesn’t do anything special to benefit from PCI graphics cards. It runs faster with PCI graphics cards (and VLB, AGP, and PCI Express cards) than with ISA graphics cards because the supporting bus is faster, so reads from and writes to video memory take less time.

PCI goes to great lengths to preserve backwards compatibility with ISA-based VGA, providing support for “VGA compatible” adapters so that they can appear in memory at the same locations and use the same I/O ports as ISA VGA cards. So accesses to the VGA registers and to the VGA buffer (at 0xA0000) go directly to the main PCI VGA compatible adapter in the system, with no change required in the operating system or programs running on it. (This is the reason why there’s a specific “VGA compatible controller” device type in PCI. Such shenanigans are impossible for other device types in PCI, which is why PCI sound cards have so much trouble providing compatibility with programs written for ISA sound cards.)

A faster bus and/or faster video memory immediately leads to higher performance in video-intensive programs because software doesn’t need to be careful about how it accesses video memory (except on CGA, and on all platforms with vertical blank synchronisation if it cares about tearing). So REP MOVSW or REP MOVSD with no waiting in software, once the program decides to write a frame, is perfectly fine, and will go faster and faster as the underlying hardware improves. On platforms where this can’t work in hardware (e.g. on an 8088 with a VGA card), the hardware takes care of specifics — for example on an 8088 the bus unit will split up 16-bit accesses.

Your question is specific to DOOM but other DOS games are in a similar situation. Later games tended to rely on VBE (often using UniVBE) to access video modes beyond those provided by VGA, but they mostly didn’t use anything beyond video-mode setup and framebuffer configuration (see also Were any DOS games (or software) known to use VBE/AF?), so improved video speed came mostly from bus speed increases, faster video memory, and speed increases in the cards themselves (which was already a factor in the ISA era, compare most Trident cards to Tseng cards for example).

For an excellent explanation of the intricacies of VGA programming and its memory layout, see Fabien Sanglard’s Game Engine Black Book series. The DOOM update loop is shown on page 185 of the DOOM book; it doesn’t use any assembly language (unlike the renderer, see pp. 290 and following), but it does have one perhaps surprising feature given the 32-bit nature of the code: VGA updates are done 16 bits at a time. Section 2.3 of the same book, pp. 59 and following, describes some of the improvements to VGA adapters around the time DOOM was released, in particular the switch to the VESA Local Bus on 486s. The benchmark table on page 287 shows the importance of the bus.

Answer 2

(When selecting an answer, use Stephen's - I just put this here because it is too much text for a comment)

Most Important: It's a Game of Raw Numbers.

We can ignore more complicated stuff and simply go for bandwidth:

• ISA had at the time a bandwidth around 16 MiB/s (*2)

• VLB (*1) and PCI offered up to 133 MiB/s bandwidth.

• A 320 x 200 screen needs 64 kB (lets say 64 KiB) (*3)

• With 30 fps, which can be considered good (*4), that adds up to ~2 MiB/s

• 2 MiB/s is 17% of the raw ISA bandwidth

• but it's only 2 % of VLB and PCI's bandwidth

That is worlds for a game like DOOM, that did in the days shined due its many ways to make 3D run on barely able hardware. Often forgotten today, Doom not only reduced detail, but as well screen size. It offered 9 sizes, from 320x200 down to 96x48 (*5), and having a letterbox around the action was common, not the exception.

Performance One Can Feel

Gaining 14% additional CPU time to operate is nothing for an application, but huge on a resource strapped game. It's the difference of running DOOM in at least one screen mode up.

And between an ISA system capable to use 320x200 and the same CPU setup with PCI of at least doubling the frame rate - that's from barely playable to lightning fast.

Either effect is quite visible. All without changing anything within the game.

Downward Compatibility is the Name of the Game

PCI (and VLB) were made to have (existing) I/O hardware appear to the system like before. VLB a bit more than PCI, as PCI. In either case VGA memory and control was mapped at the same addresses than on ISA. A worthwhile effort as all software would benefit right away without any modification. It would need no knowledge about the changed bus system - the same way a 8086 software does not need to know if it's running on a Pentium.

So it was downward compatibility of the new bus systems - made by its developers to be able to sell PCI systems. After all, who would buy an incompatible PC, one were the Flight Simulator doesn't work like on an 8088?

---

From Comments:

But how is this managed "automagically". How is this forward/upward compatibility implemented?

There is nothing magic. The VGA memory was with PCI available at the same real address as with ISA before: A0000h. No change in the (visible) HSI (*6), so no need to change the software.

Your [@StephenKitt's] improved answer implies to me that original VGA was designed with upward compatibility to a 32-bit system bus.

No, if at all, the other way around. The newer busses were the same, except faster and wider. And both changes are invisible to software. From a software PoV there is no difference on how fast a CPU runs and/or if an access is done in bytes or words. That's all covered by the CPU hardware. The only measurable difference is speed. Something software will only 'feel' in performance (which is what your question is about), but not in operation.

Also that faster busses are transparent because slower busses just introduce wait-states.

No, there is no relation between software and bus (or CPU) speed. That is, no other than over all performance. Software does not need to be rewritten for different clocked CPU's, bus width or speeds. It will just show in what it can crank thru in course of time. In case of your PCI/ISA question, DOOM is simply able to transfer a frame in less time, thus either producing more frames in a given time (aka fps), or frames with a higher resolution (selected in the option screen). Either way: Better Gaming.

---

Lesser but Related: Pentium and VLB Sucked.

I do not remember the full parts, but AFAIR Pentium chipsets and the VLB protocol did not go well with each other resulting in a meagre performance, making a Pentium-VLB slower than a 486-VLB, while Pentium-PCI did work well. This not only made VLB obsolete soon, but also added a lot of less than favourable DOOM results.

Carmack and Romero, the DOOM guys, did BTW think that VLB was the way of the future to go and PCI just a strange side development by Intel, as one of them stated at the time.

---

*1 - Never forget VLB, it was the go to for gamer at the time)

*2 - Well, ISA had no fixed defined bandwith, as it always depended on the system. Early PC managed 2 MiB/s, while original AT did 6 MiB, later AT 8 MiB. Bus clock was ties to CPU clock, so faster AT clones could apply 10..12 MHz, neting up to 12 MiB/s. Many I/O cards would comply. With later 386 passing 16 MHz CPU clock, Chipsets started to handle I/O clock as a integer, non binary fraction of CPU clock. Like 33 MHz Systems offering 6.66 MHz, 8.33, 11 or 16MHz. Again later almost arbitrary dividers were offered.

At the time of DOOM, most ISA cards worked fine at 12 MHz or above. This already brought a huge speed advantage and higher frame rates, all without VLB/PCI.

For the above calculation I use 16 MiB/s as it represents what a good ISA card could deliver when plugged into a state of the art 386/486 system. After all, while using 8 MiB/s might show an even higher speed up, I do not believe it be fair to compare the new PCI bus system with anything else than the top end of its predecessor.

*3 - 320x200 is full screen and was almost never played. Highest regular mode was 320x168 with the well known status bar at the bottom of the screen.Saving these 32 lines brought already a noticeable difference in frame rate, even on high end systems.

*4 - Looking back shows how much pampered we're today. Playing Doom at 20-30 fps was great.

*5 - Yes, way less than a Game Boy - not sure if anyone ever successfully played in that mode.

*6 - Hardware Software Interface - a fancy name for addresses by software and their semantics.

Answer 3

I can't recall the technical specifics after all this time, but I do remember that my ISA SVGA card (Trident 8900-based) would default to 8-bit bus traffic and 8-bit video-BIOS access. Getting both to 16-bit took quite some BIOS, TSR, and boot-time utility twiddling.

Games were noticeably faster in fully 16-bit mode!

So I doubt many ISA cards were actually running at their full ISA capability, which would exaggerate the perceived performance boost seen with PCI/VL-bus cards.

(N.B. I intended this as a comment, but the site upgraded it to an answer whilst I was signing in!)

Edit: ... and of course then there was the separate palaver of trying to get the video ROM shadowed by the system RAM. Basically, there was a lot of tweaking by the user needed, which in turn made it near-impossible for the coders to know precisely what to expect.

The temptation is to assume people would use the extra bandwidth to push more pixels around, i.e. to move from MCGA to a "hi-res" SVGA (640x480x256) mode; but remember that there was no standard API for that until VBE took off - see the linked question - and by that time 3-d accelerators were on the horizon.

So for the OP's question: DOOM (on MS-DOS) wouldn't behave differently depending on the data bus; it would assume an IBM VGA card. Meanwhile, ISA cards were partly nobbled by backwards-compatibility issues: my old card was expected to be fully-functional even in an XT, whereas a PCI card knows it's in a 486 or better.

Answer 4

The main issue here is the ISA bus is very slow.* The actual speed is about 2MB/sec for a 16-bit ISA device. I assume that is on an 8MHz ISA bus. To display 320x240x8bit graphics at 30 frames per second, 2.2MiB/sec of throughput is needed. The ISA bus can just about handle that, except that it consumes 100% of the CPU time to send the data and the CPU can't do anything else during that time. So half of the CPU time could be devoted to writing to the video buffer at 15 frames per second, and the other half to running the game.

It's like the days of Windows 2000/XP when DMA was disabled by default on parallel ports used by printers. Task Manager would would show 100% system CPU use while printing something, and it would print slowly.

If you had an ISA SCSI controller, it probably supported DMA. You could configure the DMA transfer speed to 8MB/sec or higher over 16-bit ISA if the motherboard would let it go that high.

I don't believe any ISA video cards supported DMA transfers. It would have required the CPU to write to RAM, and then the video card would copy the buffer out of RAM using DMA while the CPU was free to run the game.

PCI video cards are much faster. The bus supports bus mastering, so the CPU can read and write to PCI devices at nearly the full advertised speed of 133MB/sec. But I assume the same situation can occur again, where the CPU is slowed down by the typical transfer rate of around 110MB/sec. I wonder if any video card drivers have the CPU write to RAM and then instruct the PCI video card to DMA the buffer out of RAM, while the CPU is free to do other things?

Edit: There is a case where PCI can be slow too. Try running Windows with the generic VGA driver on a PCI video card, or the SVGA driver with XP. Scrolling and moving windows around is much slower than if the proper driver is installed. Notice that a lot of system CPU is used to do so. It's rather similar to the issues with ISA video cards.

• Source: https://www.electronicdesign.com/home/article/21200128/time-is-up-for-isa-based-data-acquisition