Known hardware issues

This page lists all known hardware issues that may or may not be managed by REDsdk, or that may require attention from the application workflows.

Using GLSL shaders on ATI and INTEL GPUs

GLSL shader programming is supported for all kinds of graphic cards that have the GLSL programming capabilities. However, a small restriction applies to ATI and INTEL cards on the number of mesh data channels that are accessible to a GLSL program. A GLSL vertex shader should only use:

Other data channels (such as the RED_VSH_USER0 - RED_VSH_USER3 for instance) won't be accessible to the vertex shader, if that shader is a GLSL program and executed on a ATI or INTEL GPU.

If the GLSL shader has to be executed on a geometry that has RED::MCL_USER0 data stored in it (for instance, tangent space vectors are often stored in this geometry channel), then instead of binding it to RED_VSH_USER0 as this is often done (to keep the RED::RenderCode binding straightforward) it just needs to redirect the RED::RenderCode binding to an unused input channel supported by the GLSL shader.

Dual view and hardware acceleration on legacy Windows versions

Mostly observed on Windows 2000 and Windows XP, there was a major design flaw in NVIDIA hardware about the way hardware acceleration was handled when multiple monitors were used on a single GPU. If you still operate one of these old systems, lpease right click on the windows background, select 'NVIDIA control panel' and then reach the 'manage 3D settings' tab. Then, look at the 'Multi-display/mixed GPU acceleration setting' value.

There are three values for this setting:

Extension limit in the NVIDIA control panel on legacy Windows versions

Under the 'Manage 3D settings' tab of the NVIDIA control panel lies an option called 'Extension limit'. Turning 'On' this option cause the OpenGL extension string to be clamped for backward compatibility with very old legacy OpenGL application. Turning this option 'On' may cause a problem with REDsdk that may fail to detect the hardware capabilities properly. REDsdk window initialization will fail when this occurs, so please let this option set to 'Off' as it is by default.

Custom ATI catalyst driver for REDWAY3D

We call 'Catalyst for Redway3d' the special Catalyst version that can be downloaded from our website on the private REDsdk page. This driver is recommended to use for several hardware configurations (Win 2000, Win XP 32, Win XP 64, for both consumer & professional units) as pointed out in the GPU / driver table. This driver is simply made of two DLLs: atioglxx.dll and atioglgl.dll. These DLLs must be copied into the application execution folder, and they'll automatically replace the current OpenGL driver at the startup of any OpenGL based application having the application's path in its DLL search path. The REDWAY3D version of the Catalyst driver is a legacy driver. It does work only on Windows 2000 & XP.

No stencil buffer on auxiliary VRLs

Auxiliaty VRLs that are created using RED::IWindow::CreateVRL don't support stencil bits to be packed with their depth buffers. This is due to many faulty hardware combinations that claim to support this, but that don't. Internally speaking this is related to errors in the support of the GL_DEPTH_STENCIL_ATTACHMENT flag during the Framebuffer object creation.

This behavior can be modified by changing the value of the RED::OPTIONS_FORCE_STENCIL option.

However, stencil buffers ARE available for default VRLs of windows. Nevertheless, turning on engine anti-aliasing or GPU tone-mapping will disable stencil buffers unless the force stencil option is set, due to the internal creation of Framebuffer objects by REDsdk.