July 03, 2013 posted by Michael Lorenz
Support for Sun's SX rendering engine ( found in the SparcStation 20 and 10SX's memory controllers ) has been added, both for the console and X. Both drivers support basic acceleration ( block copy, rectangle fill, character drawing in the kernel ), the Xorg driver also supports Xrender acceleration. This probably makes SX the oldest supported hardware which can do that.
SX is more or less a vector processor built into a memory controller. The 'or less' part comes from the fact that it can't actually read instructions from memory - the CPU has to feed them one by one. This isn't quite as bad as it sounds - SX has plenty of registers ( 128 - eight of them have special functions, the rest is free for all ) and every instruction takes a count to operate on several subsequent registers or memory locations ( ALU ops can use up to 16, memory accesses up to 32 ). SX supports some parallelism too - the ALUs can do up to two 16bit multiplications and two other arithmetic or logical ops per clock cycle ( 32bit multiplications use both ALUs ). The thing runs at 50MHz - not a whole lot by today's standards but it can be a significant help to any CPUs you can put into these machines.
The kernel part hs been committed a while ago ( see cgfourteen at obio ), always runs in 8bit colour with everything ( scrolling, character drawing etc. ) done by SX. Substantially faster than software only operation.
The Xorg driver ( xf86-video-suncg14 that is, it needs a recent cgfourteen kernel driver to map SX registers ) uses EXA, by default it enables basic acceleration ( Solid and Copy, hardware cursor support has been added years ago ), Xrender acceleration is incomplete and can be enabled by adding Options "Xrender" "true" to the cg14's device section in xorg.conf. For now it implements what's needed for anti-aliased font drawing, assembling alpha maps in video memory and operations KDE3 uses for drawing icons, buttons and so on. As it is now KDE3 looks mostly right - there are a few rendering errors ( for example the corners of the white frame in Konqueror's startup page, also some text is drawn with red and blue channels switched ) but nothing that would interfere with functionality.
Speed isn't great ( well, the hardware is 20 years old ) but the improvement over unaccelerated X is more than noticeable. Some benchmark numbers, all taken on an SS20 with a single 125MHz HyperSPARC:
- x11perf -comppixwin went from 26.3 to 93.7
- x11perf -compwinwin went from 8.8 to 93.5
- x11perf -aaftext went from about 4000 ( 5000 with shadow fb but that's technically cheating since not everything is drawn into video memory ) to 16000
There is still room for improvement - for now all Xrender operations work on one pixel at a time, SX has enough registers to do at least four in most cases. Also, functionality is added as needed whenever I run into it, so other things are likely broken ( I know gtk2 is, but that's easy to fix ) which is why Xrender acceleration is disabled by default.