My Opera
Cruel & unusual graphics hardware
Wednesday, July 18, 2012 12:56:20 AM
I started hacking on Sun's CG6 / GX family of graphics controllers again, mostly because a SPARCstation LX showed up on my doorstep and I found a relatively reasonably priced source for video memory modules for it. With that it's capable of running video resolutions up to 1600x1280, which makes it useful as a debug head. Sure, a 50MHz MicroSPARC is painfully slow by today's standards but it's still more than enough to run a bunch of xterms, text editors and ssh sessions.
Without the additional video memory it would top out at 1152x900 which, even though most modern TFTs support it, doesn't match up with their native resolution resulting in ugly stretching artifacts. Panels that use 1280x1024 or 1600x1200 are far more common and with the VRAM upgrade the LX can run them at native resolution.
The good news is that the LX's video output circuitry produces a nice, crisp picture even at high resolutions ( unlike, for example, shark or a whole bunch of contemporary consumer grade graphics hardware ). The bad news is that the LX's onboard CG6 is rather slow even compared to other CG6. I did most of my development work on various Turbo GX and XGX variants found on SBus cards, all are quite a bit faster. On top of that there are small differences in the actual graphics processor, and one bit me on the LX:
All CG6 have a bit in the status register which is set whenever the blitter or the drawing engine are busy. On some variants ( by coincidence all the SBus cards I have fall into this category ) there's another bit in the same register indicating that the pipeline is full, so in order to send another command my drivers would wait for that bit to clear. Now it turns out that the LX's onboard CG6 doesn't support this second bit so we have to wait until the blitter is done before sending more commands, resulting in more waiting and less parallelism between CPU and graphics controller.
While there I also added support for anti-aliased fonts to the cgsix driver, which is quite usable, despite the slow CPU, as long as there is video memory available to cache glyphs in. Of course the alpha blending has to be done by software since the CG6 doesn't even know about the concept.
Without the additional video memory it would top out at 1152x900 which, even though most modern TFTs support it, doesn't match up with their native resolution resulting in ugly stretching artifacts. Panels that use 1280x1024 or 1600x1200 are far more common and with the VRAM upgrade the LX can run them at native resolution.
The good news is that the LX's video output circuitry produces a nice, crisp picture even at high resolutions ( unlike, for example, shark or a whole bunch of contemporary consumer grade graphics hardware ). The bad news is that the LX's onboard CG6 is rather slow even compared to other CG6. I did most of my development work on various Turbo GX and XGX variants found on SBus cards, all are quite a bit faster. On top of that there are small differences in the actual graphics processor, and one bit me on the LX:
All CG6 have a bit in the status register which is set whenever the blitter or the drawing engine are busy. On some variants ( by coincidence all the SBus cards I have fall into this category ) there's another bit in the same register indicating that the pipeline is full, so in order to send another command my drivers would wait for that bit to clear. Now it turns out that the LX's onboard CG6 doesn't support this second bit so we have to wait until the blitter is done before sending more commands, resulting in more waiting and less parallelism between CPU and graphics controller.
While there I also added support for anti-aliased fonts to the cgsix driver, which is quite usable, despite the slow CPU, as long as there is video memory available to cache glyphs in. Of course the alpha blending has to be done by software since the CG6 doesn't even know about the concept.
