Hardware platforms

REDsdk is a hybrid engine, running both on the CPU and GPU of the host system. REDsdk runs on a wide range of GPUs (more than 1400 GPUs as of REDsdk 4.0) that have a very broad range of capabilities. Therefore, GPU identification and support can be a nightmare for an application that wishes to run on all types of hardware. That's why REDsdk adds built-in services that can be used by any application to automate the management of hardware detection and potentially solve issues related to this complex topic.

The GPU installation and driver management services include:

And the REDDriversBaseEditor tool to manage everything in a single tool.

Then, the following links may be useful:

REDsdk has a number of specific hardware features that can be available on some hardware classes and not on some others. See this page: GPU functional level to learn everything on hardware and on the functional level of each hardware class.

Finally, this chapter also discuss a few known hardware issues that apply mostly to legacy hardware. See here: Known hardware issues.

Common hardware issues

Besides pure hardware issues that may be problematic too, we generally refer to 'hardware issue' as any kind of display problem seen using an application rendering images with a GPU. As with any other graphic application, so called hardware issues may arise. The flow of software commands needed to display something on screen interferes with several pieces of software, stacked together. Among them, the most relevant for us are:

The operating system may contain bugs, as well as the graphic driver software and REDsdk of course. Besides that we have four kinds of problems that arise:

  1. End users unaware of their system and how to manage it (for instance end-users not knowing how to install a driver for the GPU, or even not knowing what a GPU is).
  2. Error codes returned from the API (a RED_DRV_FAIL error for instance is a good catch) using the application, eventually crashes in REDsdk.
  3. Application crashes at the driver level.
  4. Corrupted graphics showing up on screen.

Each type of problem require a specific management and REDsdk delivers a few services that may be helpful:

  1. In the case of a graphics newbie end user, the RED::IGraphicDevice interface may help guiding the user toward a driver installation for his system.
  2. Either the return code is documented and the application has made a mistake in using REDsdk, or this indicates a REDsdk problem and a bug should be submitted to REDWAY3D for fixing.
  3. The driver detection and recommendation system in the RED::IGraphicDevice interface may be of a great assistance. Changing the system driver may improve the reliability of the system and also solve graphics corruption.
  4. Same as 3.

Hardware identification API

The first step of the hardware identification API is simply to get the list of GPUs available on the target system:


Task: Identifying a computer's GPU

// Access the cluster's resource manager:
RED::Object* resmgr = RED::Factory::CreateInstance( CID_REDResourceManager );
// Get it's graphic device interface:
RED::IGraphicDevice* idevice = resmgr->As< RED::IGraphicDevice >();

// Query the list of all GPUs on the system:
RED::Vector< RED::GPUID > gpulist;
RC_TEST( idevice->GetLocalGPUs( gpulist, false ) );

// Displaying all found GPU names:
for( int i = 0; i < (int)gpulist.size(); i++ )
  int asicID = gpulist[i]._asicID;
  int vendorID = gpulist[i]._vendorID;
  RED::String name( gpulist[i]._name );
  // Do whatever appropriate here!

The RED::IGraphicDevice::GetLocalGPUs method retrieve all installed GPUs on the target computer. Note that some GPUs may not be found in REDsdk's internal database. All GPUs newer than the release date of REDsdk are of course unknown to it. This means that REDsdk may not know the name of a GPU and will have no driver recommendation for it; however REDsdk knows the asicID and vendorID of the hardware, among other parameters, so it can uniquely identify it.

Once the RED::GPUID data structure has been retrieved, we can see that if the GPU is known, then we have a set of driver recommendations for this GPU. These recommendations may be followed or ignored, based on the application's choices.

Driver identification API

Then, the driver installed for a given GPU can be retrieved, still using the RED::IGraphicDevice interface:


Task: Identifying a GPU's installed driver

// Access the cluster's resource manager:
RED::Object* resmgr = RED::Factory::CreateInstance( CID_REDResourceManager );
// Get it's graphic device interface:
RED::IGraphicDevice* idevice = resmgr->As< RED::IGraphicDevice >();

// Query the list of all GPUs on the system:
RED::Vector< RED::GPUID > gpulist;
RC_TEST( idevice->GetLocalGPUs( gpulist, false ) );

// Retrieve the installed driver for the first GPU:
RED::String drivername, driverdll;
bool newer, older;
RC_TEST( idevice->GetLocalGPUDriver( drivername, driverdll, newer, older, gpulist[0]) );

The RED::IGraphicDevice::GetLocalGPUDriver looks for the driver installed for the specified GPU. Note that the GPU must be present on the local computer (therefore, it should have been retrieved by a RED::IGraphicDevice::GetLocalGPUs).

After this step, we have more informations: we know whether the currently installed driver for the specified GPU is newer or older than the driver recommended by REDWAY3D for this GPU. This information can be leveraged for the determination of a driver update policy, as detailed below.

Choosing a driver upgrade policy

Once the graphic driver of a given system GPU has been identified, the application may recommend to change its version for the version that is recommended by REDWAY3D for using this GPU. REDWAY3D emits driver recommendations for all graphic cards it supports, for all operating systems it supports. This does not mean the the driver recommended by REDWAY3D will solve all issues! However, in many cases, installing a recommended driver can solve issues. REDWAY3D tests graphic drivers available from hardware manufacturers, and looks for the most reliable among them. Based on this information it emits recommendations for all supported GPUs on all supported operating systems.

So, real key factors are to consider here before choosing to change a driver:

  1. IF THERE ARE NO GRAPHIC ISSUES, DON'T CHANGE THE INSTALLED DRIVER: Don't recommend to change a graphic driver if there's no problem with the one installed already on the end user's system. As most of the times this will not change anything, this could still cause newer problems to appear due to the change. Please also note that some industrial environments are very picky about the installed driver revisions. Changing the installed driver could potentially cause issues with other applications on the end user machine.
  2. If there are graphic issues, please try to update the installed driver; and replace it with REDsdk's recommended version. If this is already the REDsdk's recommended version which is installed, please report your problem to REDWAY3D. We'll look for alternative versions of drivers, or investigate the problem to find a workaround, or report the problem to hardware vendors. The RED::IGraphicDevice::CheckLocalGPUDriver method may provide a good upgrade workflow, based on the different configurations that may exist on a end user computer. Please note that you may have to handle driver installation failures, as detailed here: Handling driver installation failures.

Then, you'll be probably facing the case of unknown GPUs in your application. If for instance the version of REDsdk you're using is 2 years old, many of your users may have more recent GPUs that are unknown to this version of REDsdk. In this case, REDsdk offers no driver recommendation. It does not know the GPU, therefore, it can't provide any version recommendation. The best recommendation in this case is to redirect to the hardware vendor's site to install the latest recommended driver for the card.

Please note that in all cases, even if the GPU is not known to REDsdk, REDsdk should be able to use it. Simply start REDsdk normally, and see if the RED::Factory::CreateREDWindow call works. If it returns RED_DRV_UNSUPPORTED_GPU, then REDsdk can't use that GPU. Otherwise, REDsdk should be working.

Downloading a recommended driver

REDWAY3D holds a public repository filled with all the drivers that are or that were recommended by REDsdk versions, for all graphic cards and for all operating systems. The URL to access a graphic driver can be assembled using the following construction rule:


Where 'OPERATING_SYSTEM' is one of the following:

Operating systemURL string
Windows 2000Win_2000
Windows XP 32 bitsWin_xp32
Windows XP 64 bitsWin_xp64
Windows Vista 32 bitsWin_vista_32
Windows Vista 64 bitsWin_vista_64
Windows Seven 32 bitsWin_seven_32
Windows Seven 64 bitsWin_seven_64
Windows Eight 32 bitsWin_eight_32
Windows Eight 64 bitsWin_eight_64
Any Linux 32 bitsLinux_32
Any Linux 64 bitsLinux_64
Mac OSX 64 bitsMac_osx64

And 'DRIVER_NAME' is the name of the driver as returned by the RED::GPUID driver name strings.

Example: http://www.redway3d.com/drivers/Win_eight64_NVIDIA%20Forceware%20344.11%20notebook.php

Don't forget the '_' between the operating system and the driver name.

Driver list URLs

Redway3d maintains these pages on the web that can be freely accessed:

Plus these pages that contain lists of graphic cards separated by hardware manufacturer:

Pages for each REDsdk '3.x" version also exist, using the following URL:

Replace '3.5' by any '3.x' version to query the driver pages for a legacy REDsdk version.

Handling driver installation failures

End users should be warned on the fact that supplied drivers in the REDWAY3D driver repository may not install on some computers. Laptop manufacturers often restrict the installation of 'default' drivers from hardware vendors and prevent them to install. This is a common situation. Driver pages do warn about this already, but maybe some other warning on the application side may be helpful too.

On facing this kind of problem, the end-user should be redirected toward the support section of its laptop manufacturer's website.