5 ms·

Main reason is because it's using it as a linear frame buffer rather than doing anything with textures. The old 80x25 style text modes (on x86 anyway) we're ba

Main reason is because it's using it as a linear frame buffer rather than doing anything with textures. The old 80x25 style text modes (on x86 anyway) we're basically 16bit per character on screen with the GPU rendering the text from the byte buffer which made it all highly accelerated. If you compare to things like Kitty or other GPU accelerated terminals then you'll see the speed you're expecting, but that's not built into the kernel. There is work towards enabling that though via KMSCON but that's not ready for primetime yet.

Aardwolf 4y ago
But 80x25 characters being accelerated mattered maybe in 1992, but not in 2022. This is why I mentioned software rendering as well in my response. People were able to play Unreal without GPU at resolutions like 1280x1024 at full framerates, in 1998. Does this linear frame buffer have some very restricted bandwidth or something? On modern PC's? Don't all graphics card support VESA modes that are more than fast enough for graphics? EDIT: as rightfully pointed out, in 1998 Unreal was not feasible at that resolution (it was playable in software mode though, and a 450 MHz pentium II existed). But in 2002 it definitely was for that game, which is also 20 years ago.
- bzzzt 4y ago
  In 1998, a 'standard' PC was around a 200MHz Pentium (single core) with a PCI graphics card. Having owned such a machine I can only say it will NOT render Unreal on 1280x1024 at 'full frame rate'. You needed something like a Voodoo card (which didn't do half of the job a full 'GPU' does today) and even then performance tanked at higher resolutions than 640x480 VGA...
  - poisonborz 4y ago
    It's a sea of anecdotes here, but I confirm that "any middle class" '98 PC could play Half-Life with software rendering adequately at 640x480. But look at any video game, not just 3D - OP's question from performance standpoint is valid.
  - midasuni 4y ago
    When did the voodo2 come out? Having two of them in SLI mode, one rendering odd fields and one rendering even fields perhaps? I did have a voodoo and similar at the time, with the VGA loop lead from the normal 2D card. I didn’t howver have a working linux install in 1998, as my 2D card was an SIS62something or similar, which wasn’t really supported din redhat 5.2 or perhaps not redhat6. Throw in the issues with using minicom to dial the internet (pay per minute), and having to background it and then invoke pppd, all to use linx, meant I didn’t really do linux until about 2000 when I had the combination of hardware, software (Debian - potato I think) and games (railroad tycoon 2) to make it work.
- thristian 4y ago
  There's two big limits in graphics rendering: the actual rendering calculations (upgrading to a faster GPU helps here), and transferring data/instructions from CPU RAM to video RAM (using a faster PCI protocol helps here). Getting top-notch graphical performance out of a modern GPU involves carefully designing the system to deliver all the graphics data and instructions for a given frame to the GPU just in time for it to begin rendering, so it has the maximum amount of time to complete the rendering calculations before scanning out the result to the display. The trouble is, unless we're talking about the operating system for a modern video game console, the kernel is not interested in re-architecting its graphics rendering for maximum throughput, it wants to keep things as simple as possible. That's partially because kernel code needs to be super-reliable, and also because (unlike a modern video game) it needs to support all kinds of output from modern high-end GPUs to simple memory-mapped bitmap displays to character-at-a-time serial ports, so lowest-common-denominator code wins. In a classic 1990s PC, to write a character to the screen, the CPU can write a single byte directly into the text-display part of the VGA card's memory, and a fraction of a millisecond later the VGA hardware is looking up that byte in the character ROM and sending electrical pulses down the VGA cable. In a modern PC, if the CPU wants to write a single character to the screen, it probably needs to write each pixel separately, each pixel is three or four bytes, and writing a pixel probably requires making a change to CPU RAM, preparing a command buffer, creating an "update texture" command, uploading the entire screen contents as the new texture, signalling to the GPU that a command buffer is ready, waiting for the GPU to signal that it's ready to receive, sending the command + data, and waiting for the GPU to signal that it's successfully received the data. And then the GPU actually has to draw the output into its own framebuffer, and send that to the monitor. A modern PC can send all that data much more quickly than a 1990s PC could, but the 1990s PC is much simpler, so it has much less data to send.
- mortehu 4y ago
  1280x1024 at 60 Hz is 78 million pixels per second. Color interpolation and Z buffers multiplies the number of values you work with by 4. Even if there are no overlapping objects, a 333MHz CPU would have to spend just 1 cycle per value to keep full framerate. The only way you could update the whole screen every frame on these computers was with hardware scrolling, in the style of Mario or Civilization.
  - tom_ 4y ago
    Or run at a lower resolution. Quake 2 was 60 Hz on my PC at 320 x 200.

Aardwolf 4y ago

But 80x25 characters being accelerated mattered maybe in 1992, but not in 2022. This is why I mentioned software rendering as well in my response. People were able to play Unreal without GPU at resolutions like 1280x1024 at full framerates, in 1998. Does this linear frame buffer have some very restricted bandwidth or something? On modern PC's? Don't all graphics card support VESA modes that are more than fast enough for graphics? EDIT: as rightfully pointed out, in 1998 Unreal was not feasible at that resolution (it was playable in software mode though, and a 450 MHz pentium II existed). But in 2002 it definitely was for that game, which is also 20 years ago.

bzzzt 4y ago
In 1998, a 'standard' PC was around a 200MHz Pentium (single core) with a PCI graphics card. Having owned such a machine I can only say it will NOT render Unreal on 1280x1024 at 'full frame rate'. You needed something like a Voodoo card (which didn't do half of the job a full 'GPU' does today) and even then performance tanked at higher resolutions than 640x480 VGA...
- poisonborz 4y ago
  It's a sea of anecdotes here, but I confirm that "any middle class" '98 PC could play Half-Life with software rendering adequately at 640x480. But look at any video game, not just 3D - OP's question from performance standpoint is valid.
- midasuni 4y ago
  When did the voodo2 come out? Having two of them in SLI mode, one rendering odd fields and one rendering even fields perhaps? I did have a voodoo and similar at the time, with the VGA loop lead from the normal 2D card. I didn’t howver have a working linux install in 1998, as my 2D card was an SIS62something or similar, which wasn’t really supported din redhat 5.2 or perhaps not redhat6. Throw in the issues with using minicom to dial the internet (pay per minute), and having to background it and then invoke pppd, all to use linx, meant I didn’t really do linux until about 2000 when I had the combination of hardware, software (Debian - potato I think) and games (railroad tycoon 2) to make it work.
thristian 4y ago
There's two big limits in graphics rendering: the actual rendering calculations (upgrading to a faster GPU helps here), and transferring data/instructions from CPU RAM to video RAM (using a faster PCI protocol helps here). Getting top-notch graphical performance out of a modern GPU involves carefully designing the system to deliver all the graphics data and instructions for a given frame to the GPU just in time for it to begin rendering, so it has the maximum amount of time to complete the rendering calculations before scanning out the result to the display. The trouble is, unless we're talking about the operating system for a modern video game console, the kernel is not interested in re-architecting its graphics rendering for maximum throughput, it wants to keep things as simple as possible. That's partially because kernel code needs to be super-reliable, and also because (unlike a modern video game) it needs to support all kinds of output from modern high-end GPUs to simple memory-mapped bitmap displays to character-at-a-time serial ports, so lowest-common-denominator code wins. In a classic 1990s PC, to write a character to the screen, the CPU can write a single byte directly into the text-display part of the VGA card's memory, and a fraction of a millisecond later the VGA hardware is looking up that byte in the character ROM and sending electrical pulses down the VGA cable. In a modern PC, if the CPU wants to write a single character to the screen, it probably needs to write each pixel separately, each pixel is three or four bytes, and writing a pixel probably requires making a change to CPU RAM, preparing a command buffer, creating an "update texture" command, uploading the entire screen contents as the new texture, signalling to the GPU that a command buffer is ready, waiting for the GPU to signal that it's ready to receive, sending the command + data, and waiting for the GPU to signal that it's successfully received the data. And then the GPU actually has to draw the output into its own framebuffer, and send that to the monitor. A modern PC can send all that data much more quickly than a 1990s PC could, but the 1990s PC is much simpler, so it has much less data to send.
mortehu 4y ago
1280x1024 at 60 Hz is 78 million pixels per second. Color interpolation and Z buffers multiplies the number of values you work with by 4. Even if there are no overlapping objects, a 333MHz CPU would have to spend just 1 cycle per value to keep full framerate. The only way you could update the whole screen every frame on these computers was with hardware scrolling, in the style of Mario or Civilization.
- tom_ 4y ago
  Or run at a lower resolution. Quake 2 was 60 Hz on my PC at 320 x 200.