By the summer, the Sony VAIO P that had started poulsback was out of action. A repair shop had diagnosed a motherboard failure about six weeks after the project began. The project needed another machine for hardware tests.

Around July, I bought a non-working Dell Inspiron 1210 at HARD OFF in Japan for ¥500. Its power circuit needed repair. After repairing it, I had another small laptop on which the project could continue.

Once it was running, I had a machine on which to investigate the graphics hardware again. The same laptop could stay on the bench for the next build, the next image comparison and the next experiment.

A small machine with a useful constraint

The Dell has an Intel Atom Z520 and GMA500 graphics, whose 3D engine is PowerVR SGX535. It gives the project a compact target:

  • Debian 12 i386, with a Linux 6.1 i686 PAE kernel
  • The built-in 1280 × 800 LVDS panel

The software target is a new DRM/KMS driver, Mesa Gallium and an Xorg driver working together. Installing Debian gives that work a home; it does not make the GMA500 an accelerated OpenGL device by itself.

The Atom makes unnecessary CPU work expensive. Transforming vertices on the CPU, copying whole images and waiting between stages all consume time that a small graphics workload cannot hide. That makes the laptop useful for understanding where a frame actually spends its time.

Debian is only the starting point

Putting Linux on the machine does not complete the accelerated graphics stack. Several components must agree about the same buffers and commands.

The DRM/KMS kernel driver manages GPU-visible memory, execution and display ownership. Mesa Gallium connects OpenGL applications to the SGX535 renderer, including its shaders and draw state. The Xorg driver connects that work to the desktop, where a frame must be copied or selected for scanout.

A rendered image therefore crosses several boundaries before it becomes a visible window. A mistake in one layer can appear as corruption in another. The hardware guide follows those handoffs in more detail.

Giving each result a home

Repairing the power circuit gave the project a running reference. Software testing then needed its own discipline: record the build, fix the workload and compare the output before interpreting a speed change.

A CPU check can validate a command constructor. A hardware test can show that the GPU executed a particular scene. Showing that scene correctly in X11 adds another result. Keeping those scopes separate makes a recovered machine useful as an engineering reference.

The aim is to make ordinary OpenGL applications reach the panel through that stack, then check their output and performance. Reaching one stage does not complete the others. The demo pages collect the project’s measured results separately from this account of getting the machine ready.

That repaired Inspiron gave poulsback a place to keep asking the next question, then check the answer on the machine itself.