Three coloured gears are a familiar sight in Linux graphics. For poulsback, the useful part was that the application could stay unchanged. Getting it onto the Dell’s panel meant the driver had to meet an existing program’s expectations, through Mesa and X11, instead of choosing every detail of a small native rendering experiment.
That made the turning gears a test of connections. Shader inputs, buffer objects, command submission and presentation all had to cooperate long enough for one ordinary window to keep drawing.
Keeping the application unchanged also gave the work a useful boundary. The driver had to implement the interfaces the program already used. As those implementations changed, the same familiar scene could reveal whether a fix preserved its geometry, colours and behaviour.
A real application reaches the GPU
An early integration checkpoint put Debian’s unmodified glxgears through the project’s Mesa and Xorg driver. The captured image was correct and the submitted frames completed. It was an important result, even though the path was slow and still carried expensive preparation and copying work.
At that stage, Mesa could transform vertices on the CPU while SGX535 did rasterization and fragment work. A hardware-rendered picture did not mean every stage already ran on the GPU. The Atom still had substantial work before the graphics core could begin.
Presentation developed alongside rendering. A later checkpoint moved the windowed copies into the X11 front buffer onto the native 2D core. The path from an application’s back buffer to the visible desktop had become another concrete part of the driver.
Moving the lighting onto SGX535
Moving glxgears’ two lighting vertex programs onto the GPU was a separate milestone. Mesa translated those programs into SGX535 instructions. PDS programs supplied their inputs, while the geometry hardware handled the transformed vertices. Work previously done by Mesa’s CPU vertex path could now execute on the graphics core.
Saved windowed comparisons matched the preceding CPU vertex path in the same boot. That comparison mattered alongside the speed improvement: moving a calculation onto the GPU should preserve the picture that calculation was meant to produce.
A useful milestone, with more to learn
The glxgears demo keeps the hardware capture and measurement conditions beside its selected results. With synchronization disabled, FPS describes how quickly the application advances. The panel still has its own refresh rate, and a larger window changes the balance between CPU overhead, rendering and presentation.
The next productive question was where each frame spent its time. Giving the GPU room to work follows that investigation into overlapping engines. The hardware guide explains the handoffs that make the familiar window possible.