Rants & Ramblings

Some kind soul sent me a SparcStation 20 and others sent a VSIMM module, various CPUs and a Fujitsu AG-10E graphics board. Adapting the cgfourteen driver to wscons wasn't particularly difficult - it's a dumb framebuffer after all, at least until we get documentation about the SX rendering engine found on the SS20 mainboard. So all 'acceleration' available is a shadow framebuffer in host memory and some trickery to run the console in 8bit for speed and X in 24bit. We also support a hardware cursor using the usual /dev/fb* ioctl()s and X canuse it.
The AG-10E was a little more difficult. Basically it's Frankenstein's Monster among graphics boards - a workalike to high-end graphics machinery made using off the shelf parts. It has independent framebuffers for 24bit and 8bit colour depth and a 3rd one for Window IDs. All controlled by completely different graphics chips, hooked together using an IBM RGB561 DAC. The DAC is pretty high end - it supports WIDs, 10bit gamma tables, 30bit colour and a whole bunch of other bells & whistles.
Apparently there's also a SBus-PCI bridge somewhere on the board since at least two of the graphics chips in question ( an Imagine 128 and a GLint 300SX ) only exist in PCI or AGP variants. The 3rd one, a Weitek P9100 does exist as SBus device, it's used that way in the SPARCbook 3GX and similar laptops, but it's not clear which variant has been used here, might as well be PCI since the board desing needs PCI for the other chips already.
So, why three graphics chips with their own video memory? Well, the GLint is used for 24bit colour, it has 12MB video memory according to SBus resources while the chip itself reports 16MB, plus 16MB 'local buffer' - since I don't have real documentation about this chip I don't know what exactly this additional memory is used for. SBus resources report two independent framebuffers with 6MB each. The I128 has 4MB and is used for 8bit graphics while the P9100 has 2MB which are used as WIDs - basically per-pixel information telling the DAC how to interpret the corresponding data from the other graphics chips. So you can - for each individual pixel - control wether it's drawn using data grom the GLint, from the I128, which of the GLint's framebuffers and how to convert the pixel data to actual RGB output. Options are 8bit palette, greyscale, 24bit colour, 30bit colour and so on.
This arrangement alows the kernel driver to completely ignore the GLint while the X11 driver can completely ignore the I128 and the P9100. We just switch WIDs around to make the I128's framebuffer visible when we're using the console and the GLint's when we're running X11. That way nobody's stepping on anyone else's feet.
There are two new drivers in NetBSD -current which deal with the AG-10E - agten at sbus for the kernel part and ag10e for XFree86. The kernel driver uses the I128 as console, the blitter is used for scrolling and rectangle fills, it will be used for character drawing as soon as I can figure out how that's supposed to work, unfortunately XFree86's i128 driver doesn't use colour expansion and neither does Xorg's. Besides that the driver provides access to the DAC, so far limited to a hardware cursor and a simple 8bit palette. I'll probably add support for the gamma tables at some point.
THe XFree86 driver uses the kernel driver for hardware cursor support ( using the standard /dev/fb* interface ) and otherwise provides enough glue for the 300SX part of XFree86's glint driver to run mostly unmodified. Thus we have hardware acceleration here as well, currently for screen-to-screen copies, rectangle fills with or without pattern and line drawing. The chip is actually an OpenGL accelerator which was rather popular in the mid to late 1990s, it was used in a number of more mainstream CAD boards like the ELSA GLoria series. Without actual documentation about the AG-10E itself it will be difficult to support any real 3D acceleration since most of it relies on DMAing commands, textures etc. from host memory and I don't have the faintest idea how the GLint's PCI DMA engine maps to SBus DVMA - or rather, I have no idea what kind of view the GLint has on host memory, if at all. I couldn't find documentation for any SBus-to-PCI bridge at all, let alone the one used on the AG-10E. Same about interrupts, the board's SBus resources report a single IRQ, might be the GLint's although all the graphics chips are capable of generating interrupts.
Finally there's an Analog Devices DSP ( also with dedicated memory ) present on the card - no idea what it's used for or how to talk to it either. So far my drivers ignore it and things are fine - we have a pretty decent console and accelerated X in 24bit which is more than we can do on most other graphics boards you could plug into a 32bit SPARC.