By Greg Nowak. Last updated 2026-09-05.
glxgears is a quick way to confirm that a Linux desktop can create a GLX context, render a simple OpenGL scene and present frames. Run it without vertical synchronization and it can also reveal whether frame presentation is being capped by the display.
That makes it a useful five-minute smoke test after changing a graphics driver, updating a workstation image or investigating a creative application that suddenly feels slow. It is not, however, a meaningful GPU benchmark. Treat the output as diagnostic evidence—not a performance ranking.
What can glxgears actually tell you?
If the gears appear and move correctly, the basic OpenGL and GLX path is working. If the reported rate sits close to 60, 120 or 144 FPS, synchronization is probably following the monitor refresh rate. If the rate rises substantially when synchronization is disabled, you have confirmed that the earlier result was display-limited.
The number alone does not tell you whether one driver, GPU or workstation is faster. The scene is tiny, and its result is affected by the CPU, compositor, window size, software stack and frame-presentation path. Comparing an old 9,000 FPS result with 3,000 FPS on another machine is therefore misleading.
Start by identifying the session and renderer
Before changing anything, record the environment. These commands show the desktop session, detected graphics devices, kernel drivers and OpenGL renderer:
printf 'session: %s\n' "$XDG_SESSION_TYPE"
lspci -nnk | grep -A3 -E 'VGA|3D|Display'
glxinfo -BIn the glxinfo -B output, pay particular attention to OpenGL renderer string. A named Intel, AMD or NVIDIA GPU is normally expected. llvmpipe or softpipe means Mesa is rendering in software on the CPU. Also note that the server and client GLX vendor strings describe GLX components; they are not as useful for identifying the GPU doing the work.
If the commands are missing, install the package containing glxinfo and glxgears. It is commonly called mesa-utils on Debian, Ubuntu and Arch-based systems, and glx-utils on Fedora.
Run glxgears without vertical synchronization
Recent upstream versions provide a direct swap-interval option:
glxgears -swapinterval 0Keep the window at a fixed size and let it run through several reporting intervals. To compare the synchronized and unsynchronized paths on the same machine, run:
glxgears -swapinterval 1
glxgears -swapinterval 0If your packaged version does not recognize -swapinterval, use the driver-specific fallback. For Mesa-based OpenGL drivers, including the usual Intel, AMD and Nouveau paths:
vblank_mode=0 glxgearsFor NVIDIA’s proprietary OpenGL implementation:
__GL_SYNC_TO_VBLANK=0 glxgearsThese variables apply only to the launched process. That is preferable to exporting them globally: disabling synchronization desktop-wide can introduce tearing, unnecessary GPU or CPU activity, and confusing application behavior.
| What you see | Likely meaning | Next move |
|---|---|---|
| FPS close to monitor refresh | VSync or compositor pacing is active | Use swap interval 0 and retest |
| FPS rises above refresh rate | The simple render loop is no longer display-capped | Do not treat the number as a GPU score |
llvmpipe or softpipe |
CPU software rendering is active | Check packages, device access and driver loading |
| Unexpected integrated GPU | The application is using a different device | Check hybrid-GPU or render-offload configuration |
| GLX or display error | The graphical session, remote connection or container may not expose GLX | Inspect the session and logs before replacing drivers |
Remember the Wayland boundary
glxgears is a GLX application, which means it speaks the X11 graphics interface. In a Wayland session it will normally run through Xwayland, an X server operating as a Wayland client. A successful result therefore validates that compatibility path; it does not prove that a native Wayland/EGL application or a Vulkan workload is healthy.
This distinction also makes the old habit of searching only /var/log/Xorg.0.log incomplete. Xorg sessions may still write that file, but Xwayland does not load the traditional xf86-video-* display drivers. For a wider view of the current boot, start with:
journalctl -b --no-pager | grep -Ei 'Xorg|Xwayland|drm|nvidia|nouveau|amdgpu|i915'
sudo dmesg | grep -Ei 'drm|nvidia|nouveau|amdgpu|i915'Turn the test into useful incident evidence
For a support ticket or deployment decision, capture the kernel version, session type, GPU, kernel driver, OpenGL renderer, exact command and several consecutive frame reports. Also state whether the problem affects every graphical application or only one product.
If you need a real performance comparison, test the actual application or a representative workload at the same resolution, settings, driver version, power profile and session type. That produces evidence tied to the business problem—rendering delays, unstable workstations or an unreliable production tool—instead of optimizing an animated set of gears.
If a Linux graphics issue is blocking a rollout or consuming agency delivery time, talk to Greg about turning the scattered command output into a clear diagnosis and next-step plan.
Related on GrN.dk
- Nginx 1.30 Changed the Upstream Defaults—Test Before You Upgrade
- NGINX 1.30 changed upstream connection reuse: what to check before you upgrade
- Before Your Support Bot Learns the Help Center, Test Whether It Can Forget
Need help with this kind of work?
Discuss your Linux graphics issue Get in touch with Greg.
