ConfettiFX/The-Forge v1.50

Release 1.50 - October 13, 2021 - M²H uses The Forge | Unlinked Multi GPU Support | Central Config.h | glTF Viewer improvements | Scalar High Precision Math

on GitHub

• M²H uses The Forge for Stroke Therapy - M²H is a medical technology company. They developed a physics-based video game therapy solution that is backed by leading edge neuroscience, powered by Artificial Intelligence and controlled by dynamic movement – all working in concert to stimulate vast improvement of cognitive and motor functions for patients with stroke and the aged.
  The Forge provides the rendering layer for their application.
  Here is a YouTube video on what they do:

• Unlinked multiple GPU Support: for professional visualization applications, we now support unlinked multiple GPU.
  A new renderer API is added to enumerate available GPUs.
  Renderer creation is extended to allow explicit GPU selection using the enumerated GPU list.
  Multiple Renderers can be created this way.
  The resource loader interface has been extended to support multiple Renderers.
  It is initialized with the list of all Renderers created.
  To select which Renderer (GPU) resources are loaded on, the NodeIndex used in linked GPU configurations is reused for the same purpose.
  Resources cannot be shared on multiple Renderers however, resources must be duplicated explicitly if needed.
  To retrieve generated content from one GPU to another (e.g. for presentation), a new resource loader operation is provided to schedule a transfer from a texture to a buffer. The target buffer should be mappable.
  This operation requires proper synchronization with the rendering work; a semaphore can be provided to the copy operation for that purpose.
  Available with Vulkan and D3D12.
  For other APIs, the enumeration API will not create a RendererContext which indicates lack of unlinked multi GPU support.

• Config.h: We now have a central config.h file that can be used to configure TF.

  • Created config files:

Common_3/OS/Core/Config.h
Common_3/Renderer/RendererConfig.h
Common_3/Renderer/{RenderingAPI}/{RenderingAPI}Config.h

    * Modified PyBuild.py
        * Proper handling of config options.
        * Every config option has --{option-name}/--no-{option-name} flag that uses define/undef directives to enable/disable macros. 
        * Macros are guarded with ifndef/ifdef.
        * Updated Android platform handling
      * Deleted Common_3/Renderer/Compiler.h. It's functionality was moved into Config.h
      * Moved all macro options to config files
      * Renamed USE_{OPTON_NAME} to ENABLE_{OPTION_NAME}
      * Changed some macros to be defined/not defined instead of having values of 0 or 1.
      * Deleted all DISABLE_{OPTION_NAME} macros
      * When detecting raytracing replaced ENABLE_RAYTRACING with RAYTRACING_AVAILABLE. This was done, because not all projects need raytracing even if it is available. RendererConfig.h defines ENABLE_RAYTRACING macro if it is available. So, it can be commented out in singular place instead of searching for it for every platform
      * Removed most of the macro definitions from build systems. Some of the remaining macros are:
        * Target platform macros: NX64, QUEST_VR
        * Arm neon macro ANDROID_ARM_NEON.
        * Windows suppression macros(like _CRT_SECURE_NO_WARNINGS)
        * Macros specific to gainputstatic

• glTF viewer improvements:
  • sRGB fixes
  • IBL support now with prefiltered CCO/public domain cube maps
  • TAA support on more platforms and fixes
  • Vignette support

glTF Viewer running on Android Galaxy Note 9

glTF Viewer running on iPhone 7

glTF Viewer running on Linux with NVIDIA RTX 2060

glTF Viewer running on Mac Mini M1

glTF Viewer running on PS5

glTF Viewer running on Switch

glTF Viewer running on XBOX One Original

• Specialization/Function constants support on Vulkan and Metal only - these constants get baked into the micro-code during pipeline creation time so the performance is identical to using a macro without any of the downsides of macros (too many shader variations increasing the size of the build).

Good read on Specialization constants. Same things apply to function constants on Metal

https://arm-software.github.io/vulkan_best_practice_for_mobile_developers/samples/performance/specialization_constants/specialization_constants_tutorial.html

Declared at global scope using SHADER_CONSTANT macro. Used as any regular variable after declaration

Macro arguments:

#define SHADER_CONSTANT(INDEX, TYPE, NAME, VALUE)

Example usage:

SHADER_CONSTANT(0, uint, gRenderMode, 0);
// Vulkan - layout (constant_id = 0) const uint gRenderMode = 0;
// Metal  - constant uint gRenderMode [[function_constant(0)]];
// Others - const uint gRenderMode = 0;

void main()
{
    // Can be used like regular variables in shader code
    if (gRenderMode == 1)
    {
        // 
    }
}

• Resolved GitHub Issues
  • #206 - Executing Unit Tests on Mac OS 10.14 gives a Bad Access error
  • #209 - way to read texture back from GPU to CPU - this functionality is now in the resource loader
  • #210 - memory allocation challenge - not an issue
  • #212 - Question: updating partial uniform data on OpenGLES backend - not possible with OpenGL ES 2.0 run-time
  • #219 - Question : way to support Vulkan SpecializationInfo? - support is now in the code base see above