Performing a raytrace and analysis with FREDMPC can be as simple as pressing one of the appropriate MPC toolbar buttons. Internally, the MPC request will trigger a sequence of (up to) five actions: 1.GPU device(s) initialized 2.FRED model is loaded into the GPU 3.Rays are created 4.Rays are traced 5.Ray data is accumulated
In the following discussion of these actions, the assumption is that the model has been properly configured for use with FREDMPC. Refer to the Supported Features help topic for information on how different model components are supported in FREDMPC.
The GPU device(s) will periodically be initialized by NVIDIA, typically on the first raytrace request after opening a FRED session. The initialization may take up to several minutes to complete, depending on the model and the hardware, and the user can expect to see messages in FRED's status bar relating to the compilation of "modules". During the initialization process, various tasks are performed relating to CUDA code compilation, buffer construction, loading node intersection routines, etc. After the first initialization, some aspects of the procedure will be cached and the user may notice that subsequent GPU raytrace calls (even after closing the FRED session and returning later) have little to no observable latency. Some variability in the length and frequency of the compilation time should be expected.
The FRED model is not dynamically updated or maintained on the GPUs as the model is being edited. When a document is loaded into the GPUs, it is a static representation of the model’s state at the time of the document load. If changes to the FRED model are made and desired to be included in the GPU raytrace, the modified model needs to be loaded into the GPUs again prior to GPU raytracing. If the model needs to be reloaded into the GPU, this happens automatically when the GPU raytrace is requested.
The model load time varies depending on the contents of the FRED file and the status bar will be updated to show the current step in the model loading process.
A summary of the model load process is reported to the output window after an MPC raytrace is called, an example of which is shown in the image bellow.
The row labeled "Totals" indicates the size of the FRED model representation (in bytes) that will be pushed to the GPUs. Below that, memory allocations for ray buffer, raytrace paths and the NVIDIA "acceleration structures" are given. Finally, the amount of GPU memory on each device before and after loading the model is reported. As a rule of thumb, it is desirable that the loaded model consume less than half of the global memory available on the GPU device in to prevent memory exhaustion during the GPU raytrace.
Rays to be traced on the GPUs can be created by either the CPUs or the GPUs themselves. Ray creation on the GPUs will be significantly faster than creation of the equivalent rays on the CPUs. However, only specific source configurations allow rays to be generated on the GPUs (see Supported Features for more information). Requesting rays to be generated by either the CPUs or the GPUs is handled through the raytracing modes described below.
When creating rays on the CPUs, chunks of rays are copied between the CPU ray buffer and the GPU device as needed for raytracing. Compared to GPU ray creation, the advantage of this method is that there are no restrictions placed on the source configuration.
When creating rays on the GPUs, the ray data exists entirely within the GPU device and at no point exists in the CPU ray buffer. Compared to CPU ray creation, the advantage of this method is that the overall raytrace time, including source ray creation, will be significantly faster. However, as noted above, only specific source configurations support this method. If a source configuration is unsupported by the GPUs and this method is requested, no rays will be traced and a message will be reported to the output window as shown below.
Two different modes of raytracing on the GPUs are available, either of which can be executed with 32-bit or 64-bit precision by using the option, MPC > MPC Set Ray Trace to Double Precision.
Mode #1: Trace using CPU rays In this mode, the rays are generated by FRED on the CPUs and then copied into the GPUs as needed for raytracing. After the GPU raytrace is completed, the ray data is available in the CPU ray buffer for analysis using the full complement of FREDs analysis tools. Note, however, that if ray splitting is present in the model only the parent rays will be returned to the CPU ray buffer (any child rays resulting from ray splitting are not returned from the GPU). If a detector entity or directional analysis entity has been properly configured, an Analysis Results Node (ARN) will be generated at the conclusion of the raytrace.
This mode of GPU raytracing can be called in the following ways: •Toolbar button: •Menu > MPC > MPC Trace CPU Rays
The FRED output window will display text similar to the image shown below.
For each group of rays traced on the GPUs (1,048,576 rays, or 220, per group by default), the timing for Pre-Launch, Launch and Post-Launch is reported. Pre-Launch: Rays sent from the CPU to the GPU ray buffer and prepared for tracing Launch: Rays traced on the GPUs Post-Launch: Traced rays sent from GPU back to CPU ray buffer This cycle is repeated until the total number of rays created by the CPU have been traced.At the conclusion of the Trace CPU Rays call, the rays will be available in the CPU ray buffer for analysis.
Mode #2: Trace using GPU rays In this mode, the rays are generated directly on the GPUs by any active (and supported) sources that were loaded into the GPUs. The rays are traced on the GPUs and any properly configured detector entities or directional analysis entities will generate Analysis Results Nodes (ARNs), which appear in the Analysis Results folder at the end of the GPU raytrace. The ray data is always confined to the GPUs and is never available to the user in the CPU ray buffer at any point. Raytrace results are communicated to the user through the ARNs.
Note that use of this mode requires that (a) one or more source definitions must be supported on the GPUs, and (b) one or more properly configured Detector Entities (DE) or Directional Analysis Entities (DAE) is present in the model. Strictly speaking a DE and/or DAE is not required to perform the raytrace, except that there would be no communication of the raytrace results without one.
This mode of GPU raytracing can be called in the following ways: •Toolbar button: •Menu > MPC > MPC Trace GPU Rays The FRED output window will display text similar to the image shown below.
In the output above, the source was defined with 5 million rays. The output indicates that 5 groups of 1 million rays were launched on the GPUs, with each group of rays taking ~0.15 second to raytrace. In total, 5 million rays are traced in less than 1.5 seconds.
For the example system used to generate the output above, a detector entity plane was configured to produce the detector irradiance distribution. The Analysis Results Node produced by this detector entity is automatically added to the Analysis Results folder of the FRED model at the conclusion of the GPU raytrace.
If the MPC Trace CPU Rays method is used, then analyses can be performed in two ways: •At the conclusion of the raytrace, the ray data exists in the CPU ray buffer and the full complement of FRED's analysis tools are available for use (see Coherent Field Summation notes below when coherent rays are present) •If one or more properly configured Detector Entities or Directional Analysis Entities are present in the model at the time of the raytrace request, Analysis Results Nodes will be generated automatically at the end of the raytrace
If the MPC Trace GPU Rays method described previously is used, then analyses are only performed and communicated through properly configured Detector Entities or Directional Analysis Entities.
Refer to the Supported Features help topic for information on properly configuring Detector Entities and Directional Analysis Entities for use with FREDMPC.
Coherent Field Summation Although FREDmpc does not raytrace coherent rays on the GPUs, it is capable of taking coherent rays from the CPU ray buffer and performing coherent field summation calculations on the GPUs when needed. This may happen, for example, during a coherent source power scaling operation, or as part of an irradiance analysis. Specifying the GPUs for use during coherent field summation is a state toggle found on the Analyses menu. When active, the GPUs are used for coherent field summation calculations and when inactive, the CPUs are used for coherent field summation calculations.
Refer to the Supported Features help topic for additional information.
The MPC Trace Advanced dialog allows additional options to be specified on the GPU raytrace, such as 32-bit or 64-bit precision, raytrace path tracking, logfile generation, random number seed specification, GPU ray buffer size, and maximum ancestry level, among others. Certain settings applied using MPC Trace Advanced will persist even when using the Trace CPU Rays or Trace GPU Rays modes. The MPC Trace Advanced will need to be reconfigured and re-run in order to remove these persistent settings for future Trace CPU Rays or Trace GPU Rays modes.
The MPC Trace Advanced dialog can be accessed in the following ways: •Toolbar button: •Menu > Raytrace > MPC Trace Advanced
The following options describe the MPC Trace Advanced dialog controls; note that controls whose description contains with an asterix (*) denote settings whose state is saved with the FRED Document:
There are three ways of specifying random number reseeding when using the GPUs.
Option 1: FRED Preferences By default, the “Generate a different random number sequence for every ratyrace” setting on the Miscellaneous tab of the FRED Preferences dialog determines whether the GPU raytrace is seeded with a new random number at the start of every raytrace. •If this preference is active, the CPU generates a random, unsigned integer between 0 and 264, which is then passed to the GPU as the starting random number seed value. •If this preference is inactive, the GPU seed will be set to 0 (multiple calls of a GPU raytrace will produce the same rayset each time).
Option 2: User specified random seed A deterministic, computer independent sequence of rays will be generated when a seed value is provided to the GPU. A user-specified random seed value can be supplied to the GPU raytrace using the MPC Trace Advanced dialog.
Option 3: Auto generated random seed The “auto” option will use the CPU to generate a random, unsigned integer between 0 and 264, which is then passed to the GPU as the starting seed value. The automatic reseed option can be specified on the MPC Trace Advanced dialog.
The random number seed used for a GPU trace is displayed in two locations: 1.The output window text once an MPC raytrace has been called 2.The log file, if it was requested on the MPC Trace Advanced dialog
It is possible to replace the 3D OpenGL view of the FRED model with an interactive, real-time rendered view and also generate static bitmap images of the GPU rendered model. These capabilities are useful for: (a) visually assessing the representation of the geometry that was loaded into the GPU(s) for raytracing in order to identify any potential differences with the CPU version, (b) visually assessing the geometry as represented by single and double precision, and (c) generating high quality rendered images of the model for reporting purposes.
The interactive, real time GPU rendered view can be activated by going to MPC > MPC Toggle Render Mode or by using the associated toolbar button, noting that the rendering mode follows the single or double precision flag of the document (i.e. the rendering is performed in double precision when the document is set to use double precision).
A rendered image of the GPU model can saved to a JPEG using the "File... Save 3D view as JPEG" option when the MPC Render mode is active.
Cutaway clipping and isolated views are unsupported in the GPU rendering feature.
As described in the Overview help topic, the FRED model undergoes a translation process in order to be loaded into the GPUs for raytracing. Not all features are supported for direct translation to the GPUs, so it is important to understand which items in a FRED model arrive on the GPUs and which items are ignored or approximated. The raytrace actions will also write their output information to the log file when it has been requested.
The MPC logfile is one of the most useful starting points for debugging unexpected behaviors in a GPU raytrace or analysis because it provides detailed information at each step of the MPC raytrace initialization, model load, and raytrace execution pipeline.
A log file can be generated by toggling the “Log MPC raytrace activity to a file” option on the MPC Trace Advanced dialog and specifying a full file path location. The log file will be created in the specified directory, can be viewed with any ASCII text viewer (ex. notepad). Keep in mind that the log file documents how every item in the model is translated to the GPUs. Consequently, the log file contents can be substantial and time consuming to parse.
A simple example file has been loaded into the GPUs to produce an example log file, the key aspects of which will be described in the following sections.
The log file begins with summary information pertaining to the configuration of the raytrace. Specifically, the precision mode with which the raytrace will be executed, the number of rays to be traced per launch (device total ray capacity), the random seed to be used during the trace, whether the raytrace is being forced to use Monte-Carlo mode (via an Advanced Raytrace call) and then two options pertaining to whether certain types of data collection are optionally being suppressed during the raytrace.
> FREDmpc(c) Optical Engineering Software (V21.41.0) log file. Thu Mar 31 23:04:07 2022
>>> MPCtrace command in progress...
> Floating point precision: fp32 > Device total ray capacity: 1048576 > Random number seed: 2550165348953337727 > Force Monte-Carlo: false > Collecting per surface incident ray data: true > Surface facet ray data collection: true
Next, the FRED model begins loading into the GPUs and the first item translated is the active wavelengths of the traceable sources in the FRED model, which are stored in a buffer on the GPUs. Eleven discrete wavelengths are defined in the traceable sources of this example file, as indicated in the log file text below.
>>> Loading FRED model to host. Begin...
> Loading wavelengths... Active wavelength count: 11 > Loading wavelengths. Done.
The next items loaded into the GPUs are the Raytrace Properties.
> Loading ray trace controls... [0] native support: Halt All [1] native support: Transmit Specular [2] native support: Reflect Specular [3] native support: Allow All [4] native support: Refractive Optics [5] native support: Refractive Mounting [6] native support: Mechanical > Loading ray trace controls. Done.
Materials are loaded into the GPUs next, with a summary of the approximations and limitations provided at the start of the material report. For this model, the real refractive index values of the materials are all represented without approximation at the active wavelength values of the traceable sources and no warning messages are reported.
> Loading materials... GRIN and Birefringent glass converted to sampled glass. The following generic glass attributes are ignored: volume scatter, angular dependence, position, polarization, OPL group velocity. [0] native support: Air [1] native support: Vacuum [2] native support: Simple Glass [3] native support: Standard Glass [4] native support: Optical Cement [5] native support: N-BK7 [6] native support: PCARB [7] native support: PMMA [8] native support: MgF2 > Loading materials. Done.
The next items loaded are coating models. Note that the summary information at the top indicates that the support for coating types will exclude phase terms and the power coefficients are computed as the average of S and P polarizations. Refer to the Supported Features help topic for more information on property conversions and approximations.
> Loading coatings... Supported coating attributes: power transmission (T) and reflection (R) coefficients. Approximations: T/R computed for average of S/P polarizations, coating phase is ignored. [0] native support: Absorb [1] native support: Reflect [2] native support: Transmit [3] native support: Standard Coating [4] native support: Uncoated [5] native support: Quarter Wave MgF2 > Loading coatings. Done.
Scatter model definitions are loaded next with an important note that scatter model types that do not have an equivalent GPU representation are completely ignored (i.e. are not present in the GPU version of the model). In this model, the three scatter models listed all have native support on the GPUs.
> Loading scatter data... All unsupported types are ignored. The following scatter attributes are ignored: wavelength and position dependence. [0] native support: Black Lambertian [1] native support: White Lambertian [2] native support: Harvey Shack [3] native support: Black Paint > Loading scatter data. Done.
Source and geometry definitions are loaded into the GPUs next. It is important to realize that source definitions are only relevant to the Trace GPU Rays mode of GPU raytracing. When using the Trace CPU Rays mode, the rays are generated on the CPUs and then transferred down to the GPUs for raytracing.
For geometry elements, a “native” type is a construct in FRED that has an equivalent definition in the GPU and should behave equivalently on both the CPUs and GPUs for the purposes of raytracing. Warnings are issued when a construct does not have an equivalent definition in the GPU (i.e. the construct is not natively “supported’). In general, unsupported geometry constructs are converted to an approximation using triangle meshing.
As part of processing the geometry nodes, an assessment of the importance samples assigned to each surface will be made. If an importance sample is unsupported, it will be converted to the “default” importance sample (scatter rays into the local hemisphere) and a warning will be printed in the log file. When debugging raytrace differences between CPUs and GPUs, identifying the approximated surfaces in the geometry section of the log file can be a useful place to start. For example, note that the surface "Aperture Stop 1" has been loaded onto the GPU as a facetted surface representation (line 6). At the time of this writing the GPUs do not have a native representation of CAD surface constructs (NURBs and TrimmedParametrics), so their representation is approximated by converting those surface types to triangle meshes. The quality of the surface representation is therefore dependent on the quality of the surface meshing in that case and could be the source of a subtle difference between the CPU and GPU raytrace results.
> Loading geometry and sources... Surfaces: - Trimming will force conversion to faceted surface. - The following unsupported surface attributes are ignored: glue, surf rough, aux data, sag deform. Sources: (used only for 'source trace') - Partially supported attributes: power units always assumed Watts. - Only sources with the following position/direction pairs are supported: (random 2D grid/random dir into angular range), (random 2D grid/single dir), and (random 3D volume/random into sphere). - The following unsupported attributes are ignored: polarization, coherence, position/direction apodization, acceptance filter, and all wavelength specs other than 'as specified by list'. [4] source: grid random, random direction: Solar Source [6] added as facetted surf: Aperture Stop 1 [6] importance sample: specular direction [7] added as facetted surf: Entrance Aperture 1 [7] importance sample: specular direction [8] added as facetted surf: Tailpiece 1 [8] importance sample: specular direction [10] importance sample: hemisphere (default) [11] importance sample: hemisphere (default) [12] importance sample: hemisphere (default) [14] native asphere: Surface 3 [14] importance sample: hemisphere (default) [15] native asphere: Surface 4 [15] importance sample: hemisphere (default) [17] importance sample: hemisphere (default) [18] importance sample: hemisphere (default) > Loading geometry and sources. Done.
Next comes a section pertaining to the final initialization and preparation of the GPUs prior to
>>> Loading FRED model to host. Done.
> Building device acceleration structures... Building geometry acceleration structure for custom primitives... Copying temporary custom primitive build input to device... Performing custom primitive GAS build... Freeing temporary custom primitive device build input memory... Building geometry acceleration structure for triangle primitives... Copying temporary triangle primitive build input to device... Performing triangle primitive GAS build... Freeing temporary triangle primitive device build input memory... Building instance acceleration structure... Performing IAS build... Freeing temporary device build input memory... > Building acceleration structures. Done.
> Setting pipeline compile options...
> Creating modules...
> Creating groups...
> Max ray recursion depth: 1 Pipeline ray recursion depth: 1 Info: These depths may be reset later
> Creating pipeline...
> Creating binding table...
>>> Copying FRED model from host to device(s). Begin... > Copying FRED model from host to device 0... Copying auxiliary data buffers... Copying basic geometry and surface attribute buffers... Copying Surf/DE/DAE/Source parameters buffers... Copying wavl/glass/surfprop/coating/scat buffers... >>> Copying FRED model from host to device(s). Done. > Is Doc pure Monte-Carlo: false
> Maximum ray recursion depth: 1 > Tracking ray paths: false > Maximum path events per path: 10
The last section of the log file contains the GPU raytrace output, showing the progress of the individual launches.
> Trace ray buffer begin... <0>Pre-launch <0>Launch (0 --> 1,048,575) <0>Post-launch <1>Pre-launch <1>Launch (1,048,576 --> 1,099,999) <1>Post-launch <> Post-trace > Trace ray buffer end
>>>MPCtrace command done.
> Stop Log Thu Mar 31 23:04:10 2022
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.png)
.png)
.png){kind=small}
.png)
.png){kind=small}
.png)
.png){kind=small}