Hardware, hybrid or software start

To find out the best starting mode suited for your application, please read the few lines below. We'll provide a few facts to take into consideration for the determination of how REDsdk should be initialized into your environment.

By application quality needs

The first importance difference between hardware rendering and software rendering is about the quality of the images that can be produced. An application that wishes to produce photo-realistic images should use REDsdk in pure software mode, because hardware based graphics can't reach a photo-realistic display quality.

The table below illustrates some important qualitative features that are available in REDsdk and for which rendering mode they can be used:

(*) Area lighting and shadowing refer to rectangular area lights (RED::ILightShape::SetRectangularAreaLight).

Some ray-tracing features (such as basic reflection / refraction / shadows) can be processed using the hardware layer. However, using these features will cause a slowdown of the rendering system, and the framerate of the application may drop to only a few frames per second, depending on the selected rendering options.

So we can see from the table above that for any application aiming at producing high quality images we have no other choice than to go for a hybrid or full software rendering mode.

By application performance

If the application need to render real-time graphics at 30+ images per second such as for a viewport, simulation or game application, then using REDsdk's hardware mode is a natural choice. However, some scenarios may push you to consider using hybrid mode instead.

If the application needs to access REDsdk's software acceleration structure (RED::IGeometryDatabase), to perform some auxiliary calculations (interference checking, acoustic propagation, thermal analysis, etc...), then a hybrid mode REDsdk start may be requested to leverage these API services. On the other hand, if the application renders high quality images, but wants to leverage the real-time tone-mapping speed, it may consider starting REDsdk in hybrid mode too.

Besides these scenarios, choosing between pure hardware or software mode is generally driven by the application's need. From that fact, starting in hybrid mode may be considered for the application to dynamically change the rendering mode according to the display needs, that can vary for the accomplished tasks.

Hybrid mode specifics

REDsdk's hybrid mode is quite specific. A REDsdk application can dynamically switch the rendering call it uses to render using the graphic hardware or in software at will. Different windows can be rendered using different methods each. One must be aware of the fact that the hybrid mode consumes more memory than the two other modes for the management of textures (and only for textures): in hardware mode, textures are stored on the video memory (GPU), and a copy of the textures is generally stored by the OpenGL layer of the operating system (this may depend on the used hardware / OS). In software mode, there's no OpenGL layer, and one copy of the texture is kept by REDsdk itself for its own rendering needs. In hybrid mode, both a video memory version of the image (plus the possible driver version) and a software version of the texture are kept alive in memory.

Software startup

Hardware event loop vs. software event loop