Assessing the state of r128 graphics stack

Now that I decided to work on r128 (ATI Technologies RAGE 128) graphics stack, here is my assessment of the state of the graphics stack.

  • Standby resume does not work

Not surprising considering that FOSS (Free and Open Source Software) graphics developers back in early Year 2000 did not really care much about hardware state recovery from ACPI S3 State (Suspend to RAM). Since I do not really like keeping the computer on when I am not using it (even with a desktop computer), this is probably the first item I hope to fix. More analysis on this matter in a separate post.

  • EXA based 2D acceleration is fairly buggy

There was a developer who added this functionality in Year 2012. Unfortunately, he did not fully debug the code before committing the new code, so it creates all kinds of rending problems on one’s desktop.

  • Contains FBDEV and VBE mode setting code paths

In general, I am not a fan of complex, non-preemptive, multitasking OSes (yes, that was a big deal in the early Year 2000s) calling VBE (VESA BIOS Extension) for mode setting. I will like to get rid of it. That being said, some hardware specific information like PLL reference frequency appears to come only from the Video BIOS (there is a table entry that tells the graphics device driver about the PLL reference frequency) according to RAGE 128 technical documentation. This means that it is basically impossible to wean 100% off of Video BIOS. Probably what is going to happen is that r128 graphics stack will continue to use the hardware information that comes from the Video BIOS, and handle mode setting based on the information provided, but likely get rid of FBDEV and VBE mode setting code paths. Considering the age of r128 graphics stack, it is likely going to end up as a UMS / KMS dual mode setting graphics stack similar to what I am trying to do with OpenChrome graphics stack.

  • Lacks clear separation of display controllers (CRTC) and output devices

OpenChrome graphics stack has clean separation of display controller (people used to call this CRTC or Cathode Ray Tube Controller starting around ’70s until fairly recently since no one makes real CRTs for new displays anymore) and output devices. I will likely try to separate VGA, FP, DVI, and TV after I gain some programming experience with the hardware and after I obtain a laptop containing RAGE 128 (I think they were called RAGE Mobility 128, RAGE Mobility M3, and RAGE Mobility M4 back around Year 2000).

One more interesting thing I have observed after doing some digging is that RAGE 128 and early Radeon hardware (i.e., R100) appear to share practically the same display controller. This is a pretty good example of ASIC reuse (i.e., reusing the portions of the ASIC design) from a hardware design perspective. Of course, it helps reduce the burden of having to rewrite and test the software code as well. What this means is that I can use Radeon DRM code as a reference at least for the FP and DVI portion of the code if I get stuck with the development.


5 thoughts on “Assessing the state of r128 graphics stack

  1. PLEASE, PLEASE, PLEASE take a look into nouveau nv30/nv40. Those PCI-Express cards exist in millions on the planet. They are all broken with recent gnome/plasma. The nvidia binary blob have stopped supporting those and the bugs about those are reported since YEARS! Those cards exist in PCI, AGP and PCI-Express. For example the nvidia 6200 PCI dont work, the nvidia 6600 PCIExpress dont work, the nvidia 7900gtx make same problems, … . The whole system is crashing – and none of the developers care about that – for years! RedHead pays as far as i know 3fulltime developers and none of those care about that! Some of the nv30/40 chips are also inside of mainboards als intgrated GPU. The mainboard support 8-core cpu and 16gb of ram. Works really fast with SSD – and because the nouveau developers dont care about the issues, its intgrated GPU is useless with linux. The mainboard is beeing produced NEW recently and can be bought new on the market! This is insane. I have spend over 100hours in reporting this to every single developer of nouveau. Noone cares. PLEASE help. Please


    • Considering that I am now trying to fix another broken graphics stack, I do not have the time to work on Nouveau.
      I tend to limit my work to those second tier underserved graphics stacks like OpenChrome and r128 since it is somewhat easier to further development it.
      I have seen Nouveau source code (Nouveau DRM) and my honest opinion about it is that at this point only the people who developed it can fix the issues.
      It is very complicated code, but so is Radeon DRM and Intel Graphics DRM.


    • How about buying a GPU from a vendor that supports Linux? Like AMD or Intel? These days, if you buy Nvidia, it’s your own fault. I’ve been running AMD GPUs since r300 days, and while there were some bumps in the past, today it just works. And they support Linux by contributing upstream.


  2. yes, +1 for nvidia igp, but there is a lack of documentation.
    Matrox graphics cards also need a lot of work
    again, thanks for your work Kevin


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s