glxgears gives the driver a useful existing application to run. poulscube adds a workload whose scene we can understand and change ourselves. The project’s neon logo becomes coloured geometry, with perspective, depth and a moving arrangement of cube pieces. The compact scene exercises a useful route through the stack without hiding it inside a large application.
The important feature is that the same scene can answer several different questions. Does the image survive a compiler change? Which part of a frame takes time? How much work is the Atom doing before the GPU can start?
Small enough to explain
Wrong vertex inputs, face orientation and depth handling show up directly in the cube. The wordmark and surrounding geometry add other shapes and draw state. Keeping the scene small makes it practical to inspect a failed frame and connect it to a particular part of the rendering path.
Even the early on-screen statistics found something useful. The HUD introduced a uniform-colour draw alongside vertex-colour geometry, exposing a state combination that the first frame builder refused. Later versions print timing and CPU information to standard output. The instrument itself had become a test case.
Moving vertex shading onto the GPU changed the profile of the tested poulscube workload. Profiling no longer found samples in Mesa’s CPU vertex interpreter or draw module. That narrowed the next question to the remaining CPU work and the schedule shared by geometry, rasterization and presentation.
A picture and a measurement
For image comparisons, the lab fixes the application’s clock and reads its GPU back buffer at selected frames. That makes repeated poses comparable. A timed run instead advances normally, without that capture clock or frame readback. Combining those two modes would change the quantity being measured.
Repeated timing samples help separate a useful result from a short peak. FPS describes application throughput, while CPU time per frame helps locate the work behind it. Disabling synchronization can let that throughput exceed the panel’s refresh rate. A small window and a fullscreen image also place different demands on the same hardware.
The poulscube demo collects measured results, their build identities and the measurement procedure.
The same program has another job
The homepage loop is an export of the real poulscube program rendered with Mesa llvmpipe in Docker. It supplies a compact animated visual. Its playback cadence is separate from the hardware measurements made on the Dell.
The cube also helped expose why faster shaders were only one step. Giving the GPU room to work follows its frame trace into overlapping engines and shared memory. The hardware guide explains those stages, and the glxgears demo keeps an independent application beside our own test.
The next workload follows an image through several GPU passes. Teaching SGX535 to build its own mipmaps extends that testing approach to textures and framebuffer state.