Rants & Ramblings

I got me a new toy - a Blade 2500, 2x 1.28GHz US-IIIi, 4GB RAM and two so far unsupported graphics boards, namely an XVR-500 and an XVR-1200. Of course I had to do something about the graphics boards.
As it turns out both use different variants of 3Dlabs Wildcat OpenGL accelerators to which not a shred of documentation is publicly available. Linux and OpenBSD support them to some degree, OpenBSD even has some acceleration for some of them, but all very hacky and with loads of unanswered questions.
The problem with these boards is that we get the hardware in a quite insane state - there are two 8bit framebuffers, two 32bit framebuffers, and somewhere there's a control plane which selects for each pixel from which framebuffer the colour information comes. Unfortunately this control plane contains garbage ( pixels appear randomly selected from the two 8bit framebuffers ) and we have no idea how to access it, so what both OpenBSD and Linux do is to do all drawing operations in both framebuffers to make sure the pixels show up.
This approach has a few distinctive disadvantages - it's slow, and when you do scrolling operations you can see which pixel belongs to what framebuffer since they scroll one after the other ( of course the latter point is moot on boards where OpenBSD supports acceleration ).
To get around this my driver goes a different route - it uses a shadow framebuffer in main memory. Although wsdisplay already supports shadow framebuffers I couldn't use it since I still need to update two framebuffers, so I had to write my own. All operations are done on the shadow buffer first and then copied into both framebuffers. This has the following advantages:

• all framebuffer reads over the PCI bus are eliminated
• all drawing operations that involve reading from the framebuffer are done in cached memory
• copying data from the shadow buffer to the graphics board happens from cache
• all drawing operations are done only once, into cached memory, and copying the results to the graphics board is much faster than repeating the drawing operation

The result is speed which can rival some older accelerators, at least if you stick the board into a 64bit/66MHz slot.
That said, the wcfb driver has been tested with XVR-500 and XVR-1200 boards in a Blade 2500 and an Ultra 60, it should work fine in other machines ( as long as the firmware sets up a usable graphics mode ) and it will probably work with other Wildcat-based graphics boards like the Expert3D series, XVR-600 etc.