glxgears Without VSync: A Practical Linux Graphics Check

Illustrated infographic summarizing: Glxgears No Vertical Synchronization

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 -B

In 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 0

Keep 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 0

If 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 glxgears

For NVIDIA’s proprietary OpenGL implementation:

__GL_SYNC_TO_VBLANK=0 glxgears

These 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

A glxgears result is most useful when it points to the next diagnostic step.

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

Need help with this kind of work?

Discuss your Linux graphics issue Get in touch with Greg.

Sources

Last modified

2026-09-05