glxgears Without VSync: What the FPS Can Tell You

By Greg Nowak. Updated 25 October 2026.

When a Linux workstation starts struggling with a design tool or a 3D viewport, you need somewhere sensible to begin. glxgears provides a quick check that the desktop can create a GLX context and render a simple OpenGL scene. Running it without vertical synchronization helps reveal whether its frame rate is being limited by display timing.

For an operations lead or agency team, the useful outcome is a narrower investigation: check the rendering path, identify the device doing the work, then test the application that is delaying delivery. A large FPS number alone cannot justify a hardware purchase or approve a workstation rollout.

glxgears in short

glxgears is a small OpenGL demo from Mesa Demos. It draws three rotating gears and prints a frame count every five seconds, such as 300 frames in 5.0 seconds = 60.000 FPS. By default it waits for vertical sync, so on a 60 Hz screen it reports about 60 FPS, and it usually says Running synchronized to the vertical refresh at startup. To run it without VSync, use one of these:

glxgears -swapinterval 0          # ask glxgears itself for swap interval 0
vblank_mode=0 glxgears            # Mesa drivers
__GL_SYNC_TO_VBLANK=0 glxgears    # NVIDIA's proprietary driver
glxgears -info                    # also print the renderer it runs on

A much higher FPS without VSync tells you the cap is gone. The number itself is not a GPU benchmark. The sections below cover what the test does and does not prove.

What does this graphics check actually prove?

Moving gears confirm that this particular OpenGL and GLX path works. They do not establish that hardware acceleration is active, that every graphics API works, or that your production application will perform well.

The scene is small and simple. CPU overhead, window size, driver behavior and the desktop compositor can all affect its reported frame rate. Treat the test as a way to identify obvious failures and timing constraints. For a performance comparison, use a representative project in the application your team actually runs.

Identify the session and renderer first

Open a terminal inside the affected graphical session, using the same user account as the application. Start with:

uname -r
printf 'session: %s\n' "$XDG_SESSION_TYPE"
lspci -nnk | grep -A3 -E 'VGA|3D|Display'
glxinfo -B

If the utilities are missing, install your distribution’s package containing glxinfo and glxgears; package names vary. Record the desktop environment and distribution version too. An SSH connection, container or remote desktop can expose a different graphics path from the local workstation.

Read the OpenGL renderer string, rather than relying on the installed GPU or kernel driver alone. llvmpipe and softpipe identify Mesa software renderers. That may be expected in a virtual or remote environment, but it deserves investigation on a workstation intended to use its GPU. Mesa’s documentation also identifies overrides such as LIBGL_ALWAYS_SOFTWARE that can force software rendering.

An integrated GPU is not automatically the wrong choice. Compare the renderer with the application’s requirements. On supported Mesa configurations, DRI_PRIME=1 glxinfo -B lets you inspect the first non-default GPU; it is not a universal NVIDIA offload command.

How to run glxgears without VSync

Begin with the direct command:

glxgears -swapinterval 0

The Mesa Demos source distributed by Debian documents the swap-interval option. Zero requests swaps without waiting for vertical refresh, subject to the available GLX extensions and driver behavior.

For a repeatable comparison, run these separately, closing the first window before launching the second:

glxgears -geometry 800x600 -swapinterval 1
glxgears -geometry 800x600 -swapinterval 0

Keep the window visible and unchanged. Let each run report several intervals, and save the startup messages as well as the FPS output. Interval 1 normally follows refresh timing, although driver overrides can change the behavior.

If your build lacks the option, or the driver overrides it, try the relevant process-level setting. For Mesa OpenGL paths that honor its vertical-refresh configuration:

vblank_mode=0 glxgears

For NVIDIA’s proprietary OpenGL implementation, NVIDIA documents this setting:

__GL_SYNC_TO_VBLANK=0 glxgears

Use one setting appropriate to the active renderer. These assignments affect the launched process and its children. Keep them out of global shell configuration: an uncapped test can consume unnecessary resources and may introduce tearing.

Use the result to choose your next step

A result that stays capped does not, by itself, establish a faulty driver. The application’s request and the desktop’s presentation behavior are separate parts of the path.

On Wayland, understand what you are testing

glxgears uses the X11 GLX interface. In a Wayland session it normally runs through Xwayland, which the Wayland documentation describes as an X server acting as a Wayland client. Success here does not validate a native Wayland/EGL application or a Vulkan workload.

That also changes where to investigate. Xwayland does not use the traditional xf86-video-* drivers, so an old Xorg log may be irrelevant. On systems using systemd, start with the current boot journal:

journalctl -b --no-pager | grep -Ei 'Xorg|Xwayland|drm|nvidia|nouveau|amdgpu|i915|xe'
sudo dmesg | grep -Ei 'drm|nvidia|nouveau|amdgpu|i915|xe'

These are broad filters, not diagnoses. Keep surrounding log entries when investigating errors; journal visibility and kernel-log access depend on local permissions.

Make the evidence useful for a rollout or support ticket

Capture the session, kernel, GPU, renderer, exact commands and consecutive frame reports. Add the affected application version, a reproducible task, and what changed before the problem appeared. Where possible, compare with a working workstation using the same project, settings and power profile.

Agree on a practical acceptance check: the real task completes reliably, its viewport remains usable, and the original fault no longer reproduces. If graphics problems are holding up a rollout or agency delivery, talk to Greg about reviewing the evidence and defining a focused investigation and validation plan.

Quick answers

Which package has glxgears?

mesa-utils on Debian, Ubuntu and Arch, and glx-utils on Fedora. The same package gives you glxinfo.

Does glxgears work on Wayland?

Yes, through Xwayland, so it tests the X11/GLX path rather than native Wayland. For a native check, the mesa-utils package on Debian 13 and Arch also ships eglgears_wayland and es2gears_wayland, plus vkgears for Vulkan.

vblank_mode=0 changes nothing

vblank_mode is a Mesa setting. Run glxinfo -B: if the vendor is NVIDIA, use __GL_SYNC_TO_VBLANK=0 instead. If the FPS still sits at the refresh rate with the right variable, the desktop compositor may be pacing the window; try glxgears -fullscreen before blaming the driver.

What FPS should glxgears show?

With VSync on, your monitor's refresh rate: about 60, 120 or 144. Without VSync, whatever the driver manages for a tiny scene. Compare runs on the same machine, window size and session, not numbers from a forum thread.

Related on GrN.dk

• Before You Buy a GPU: Test Your Team’s Local AI Workload
• Nginx 1.30 Changed Upstream Connections: What to Test Before You Upgrade
• AI automations need a spend dashboard before the first runaway bill

Need help with this kind of work?

Discuss your Linux graphics issue with Greg Get in touch with Greg.

Sources

• Mesa Demos glxgears source — Debian Sources
• Mesa environment variables
• Mesa vertical-refresh configuration definitions
• NVIDIA Linux driver: OpenGL environment variables
• Wayland: X11 application support