glxgears is a useful integration check: an unchanged OpenGL application must pass through Mesa, the shader compiler, GPU submission and X11 presentation to put its gears on the screen.
The frame above was read from the GMA500’s GPU back buffer during a deterministic image capture. In the capture build, the GPU executes the lighting vertex shaders as well as rasterization and fragment work. Windowed presentation uses X11 Present copies on the 2D core.
Measured on the Dell
| Window | FPS | Date | Measurement |
|---|---|---|---|
| 300 × 300 | 386 | 2026-11-03 | Median of three repeats |
| 640 × 640 | 115.8 | 2026-11-03 | Median of three repeats |
- Platform
- GMA500 · Debian 12 i686
- Governor / swap interval
- ondemand / 0
- Measured build
5c985afe34d2
The measured run completed without GPU faults. Work on CPU overhead continues.
Median of post-startup five-second FPS samples in each 21.5-second run, then the median of three runs per size. Synchronization is disabled.
Window position also matters on this hardware. An alignment experiment found that an unaligned destination made the presentation copy and the overlapping raster stage slower. The values here belong to the recorded run and window geometry; they are not a promise for every desktop layout.
Rendering status
The GMA500 stack passes selected framebuffer, frame-layout and resize checks. Full API and FBO coverage remain in progress.
What the result tells us
These gears exercise a real path through the graphics stack. Their FPS helps locate overhead and compare a specific workload across changes. Broader graphics performance, image correctness and OpenGL conformance each need their own tests. With synchronization disabled, application throughput can exceed the number of frames the panel displays.
Read Giving the GPU room to work for the 2D-copy/raster overlap work.