[Updated Jan 6, 2026]
VPixx products don’t require a “gaming-class” graphics processor (GPU) to achieve high performance—our hardware does much of the heavy lifting.
This page explains what to look for when choosing a GPU, what can go wrong, and how to quickly validate your setup.
Minimum display output requirements
|
Product |
Resolution & refresh requirement (stimulus video input) |
Recommended video protocol(s) |
|---|---|---|
|
VIEWPixx /3D |
1920 × 1080 @ 120 Hz |
Dual-Link DVI (native) If needed: Active DisplayPort → Dual-Link DVI adapter (provided with purchase) |
|
VIEWPixx /EEG |
1920 × 1080 @ 120 Hz |
Dual-Link DVI (native) If needed: Active DisplayPort → Dual-Link DVI adapter (provided with purchase) |
|
VIEWPixx3 /OLED |
2560 × 1440 @ 120 Hz |
DisplayPort |
|
DATAPixx3 |
Depends on the connected display |
DisplayPort |
|
PROPixx |
1920 × 1080 @ 120 Hz (input). High-speed modes use a 120 Hz input and are sequenced by the projector. |
DisplayPort |
|
TRACKPixx |
Depends on the connected display |
DisplayPort |
If you’re working with older or legacy VPixx hardware, contact VPixx Support for configuration recommendations.
Key issue: pixel identity (a.k.a. passthrough)
Some of our timing, synchronization, and high bit-depth tools rely on pixel identity passthrough: a true one-to-one mapping between the pixel values your software outputs and the values your GPU sends to the display.
Many modern GPU pipelines may apply “helpful” processing such as:
-
dithering (spatial or temporal)
-
post-processing / color enhancements
-
output “jitter” or pixel-level adjustments
-
OS- or driver-level “image improvements.”
These can break pixel identity and, in turn, disrupt our tools that depend on it.
On many systems, these behaviours can be disabled. On some driver/GPU/OS combinations, they cannot be reliably disabled, posing barriers to hardware usage.
Unfortunately, the tests for detecting these behaviours require specialized equipment (like VPixx devices) to monitor the video signal output. It is therefore difficult to fully test a system in advance to know its compatibility with our products. Even in cases where the specifications ‘look good,’ there may be bugs that are not discoverable until after installation.
In the past, we maintained a simple list of “known problem GPUs” flagged for features that could not be disabled. The issue is that these problems often depend on the exact driver version, OS version, and output path, and that can change over time.
Now, we recommend running our diagnostics as soon as possible, before any data collection, to identify GPU issues and adjust your system as needed.
Running diagnostics
As soon as your equipment is set up, run the diagnostic tests in our Diagnosing and Disabling Dithering in the Graphics Pipeline guide. These tests will:
-
indicate whether pixel identity is intact on your system
-
help identify whether the issue is likely driver-level dithering or post-processing
-
suggest the most common toggles/settings to try (when available)
If disabling unwanted behaviour doesn’t work, you may need to try a different GPU.
We appreciate that this is a frustrating process, and we are working on a public database of customer-submitted tests results that should provide data on recently validated systems in the field.
Best practices for maintaining a stable graphics pipeline
We recommend:
-
Run our diagnostics as early as possible, and after every update or change to your system
-
Avoid updating GPU drivers mid-study unless absolutely necessary
-
Document your working configuration (OS + GPU + driver + cabling)
If you encounter an unresolved passthrough issue, send your results to VPixx Support so we can track patterns and update guidance.