My Opera
Alpha-blending vs. FFB
Sunday, December 25, 2011 6:50:28 AM
Sun's Creator / Creator3D / Elite3D family of graphics boards is a strange bunch, compared to what you'd find in PCs. Their distinguishing design choice is their use of 3dRAM, which is marketing speak for video memory with built-in ALUs. The idea is to conserve video RAM bandwidth by eliminating or at least greatly reducing read-modify-write cycles. For this purpose the chip supports many different views on its memory:
Each pixel consists of 96 bits of information on the 3D models - front and back, Z and stencil buffer, the non-3D models only has 32bit per pixel - just one framebuffer, no double or Z buffering available.
So, in order to draw anti-aliased fonts in the ffb driver my first idea was to program the ALUs for a * fg + (1 - a) * bg alpha blending, set the colour source to constant so fg in the formula will come from the foreground colour register instead of pixel data written to the framebuffer. Unfortunately there is no mode to have the background colour come from a register as well so in order to draw a character we first have to fill the character cell with the background colour. This isn't too bad, if we're drawing a space we can stop right there and skip the whole alpha blending business. We have to wait for the drawing engine to finish anyway since changes in ALU programming only take effect when the engine is idle. Now we should be able to just memcpy the alpha map for the character into the 8bit smart aperture corresponding to the X channel, in this case alpha. Unfortunately this doesn't work, if I do this I end up with colour data from the pixel I write to being fed to the ALU, if I write only the alpha value into the 32bit smart aperture it uses the colour from the foreground register. Ah well, still 32bit writes per pixel but at least I don't have to combine alpha and foreground colour like Xorg's sunffb driver does.
- Five 'dumb' apertures, which bypass the ALUs and access memory directly. One 32bit per pixel one and four 8bit views, one for each component ( red, green, blue, X - depending on context that's either WID or alpha )
- Six 'smart' apertures which access memory through the on-chip ALUs and that was may have all sorts of side effects like bit operations, alpha, depth cueing, z-buffering etc. applied. One for 32bit per pixel, one for each channel and a 64bit view through which both pixel and Z-buffer data are visible.
Each pixel consists of 96 bits of information on the 3D models - front and back, Z and stencil buffer, the non-3D models only has 32bit per pixel - just one framebuffer, no double or Z buffering available.
So, in order to draw anti-aliased fonts in the ffb driver my first idea was to program the ALUs for a * fg + (1 - a) * bg alpha blending, set the colour source to constant so fg in the formula will come from the foreground colour register instead of pixel data written to the framebuffer. Unfortunately there is no mode to have the background colour come from a register as well so in order to draw a character we first have to fill the character cell with the background colour. This isn't too bad, if we're drawing a space we can stop right there and skip the whole alpha blending business. We have to wait for the drawing engine to finish anyway since changes in ALU programming only take effect when the engine is idle. Now we should be able to just memcpy the alpha map for the character into the 8bit smart aperture corresponding to the X channel, in this case alpha. Unfortunately this doesn't work, if I do this I end up with colour data from the pixel I write to being fed to the ALU, if I write only the alpha value into the 32bit smart aperture it uses the colour from the foreground register. Ah well, still 32bit writes per pixel but at least I don't have to combine alpha and foreground colour like Xorg's sunffb driver does.
