Update docu and changelog

Author: johguenther

CHANGELOG.md

@@ -3,19 +3,12 @@ Version History
 
 ### Changes in v2.7.0:
 
--   New minimum ISPC version is 1.16.0
--   Fixed rendering of depth buffer in the example apps
--   Dependencies Google Benchmark, GoggleTest, and Snappy moved
-    out-of-source to superbuild ExternalProjects
--   The multidevice module contains an new OSPRay Device implementation
-    that delegates work to any number of subdevices. This is an
-    experimental feature in this release but we invite feedback.
--   SciVis Renderer now ignores normal/albedo/depth hits on surfaces
-    that are fully transmissive (Material `d = 0`).
--   Changed the behavior of background rendering in SciVIs Renderer to
-    more closely reflect that of the Path Tracer
-    -   Background hits are rendered black on the normal map
-    -   Background hits are rendered in background color on the albedo map
+-   Add support for transformation and camera Motion Blur (with the path
+    tracer) via `shutter` parameter of the camera and `motion.transform`
+    array and `time` parameter of the instance and camera
+-   OSPRay can now be built for ARM64 CPUs with NEON (e.g., Apple M1)
+    using the superbuild. Thus, new minimum versions are for ISPC
+    1.16.0, for Embree 3.13.1 and for rkcommon 1.7.0
 -   OSPRay now requires minimum Open VKL v1.0.0 to bring the
     following improvements:
     -   Configurable `background` values for all volume types (default
@@ -25,21 +18,28 @@ Version History
     -   Structured regular volumes now support tricubic filtering and
         more accurate gradient computations as well as more robust
         isosurfaces
+-   The multidevice module contains a new OSPRay device implementation
+    that delegates work to any number of subdevices. This is an
+    experimental feature in this release but we invite feedback
+-   SciVis Renderer now ignores normal/albedo/depth hits on surfaces
+    that are fully transmissive (material `d = 0`)
+-   Changed the behavior of background rendering in SciVis renderer to
+    more closely reflect that of the path tracer: Background hits are
+    rendered in background color in the albedo buffer and black in the
+    normal buffer
+-   The SciVis renderer does not compute depth of field (DoF) anymore,
+    as this effect does not align with the SciVis renderer definition
+    and exposed artifacts
+-   Fixed crash on exit when using the MPI device
+-   Fixed rendering of depth buffer in the example application
 -   The first argument to material constructor `ospNewMaterial`, i.e.,
     `renderer_type`, is now deprecated and will be removed in a future
     release. AO and SciVis renderers still assume "obj" like behavior
     for all material types
--   Add support for transformation and camera Motion Blur (with the path
-    tracer) via `shutter` parameter of the camera and `motion.transform`
-    array and `time` parameter of the instance and camera
 -   Deprecated the `xfm` parameter of the instance, use `transform`
     instead
--   The SciVis renderer does not compute depth of field (DoF) anymore,
-    as this effect does not align with the SciVis renderer definition
-    and exposed artifacts
--   OSPRay can now be built for ARM64 CPUs with NEON (e.g., Apple M1)
-    using the superbuild. A minimum of ISPC 1.16.0 is required to
-    compile OSPRay for ARM64 CPUs.
+-   Dependencies Google Benchmark, GoggleTest, and Snappy moved
+    out-of-source to superbuild ExternalProjects
 
 ### Changes in v2.6.0:
 

README.md

@@ -234,7 +234,7 @@ The following errors are currently used by OSPRay:
   OSP_INVALID_ARGUMENT   an invalid argument was specified
   OSP_INVALID_OPERATION  the operation is not allowed for the specified object
   OSP_OUT_OF_MEMORY      there is not enough memory to execute the command
-  OSP_UNSUPPORTED_CPU    the CPU is not supported (minimum ISA is SSE4.1 on x86_64 and NEON on Arm64)
+  OSP_UNSUPPORTED_CPU    the CPU is not supported (minimum ISA is SSE4.1 on x86_64 and NEON on ARM64)
   OSP_VERSION_MISMATCH   a module could not be loaded due to mismatching version
   ---------------------- -------------------------------------------------------
   : Possible error codes, i.e., valid named constants of type `OSPError`.
@@ -1402,7 +1402,7 @@ All light sources accept the following parameters:
 
   float     intensity                 1  intensity of the light (a factor)
 
-  uchar     intensityQuantity            `OSPIntensityQuantity` to set the radiative
+  uchar     intensityQuantity            `OSPIntensityQuantity` to set the radiometric
                                          quantity represented by `intensity`. The
                                          default value depends on the light source.
 
@@ -1411,7 +1411,7 @@ All light sources accept the following parameters:
   : Parameters accepted by all lights.
 
 In OSPRay the `intensity` parameter of a light source can correspond to
-different types of radiative quantities. The type of the value
+different types of radiometric quantities. The type of the value
 represented by a light's `intensity` parameter is set using
 `intensityQuantity`, which accepts values from the enum type
 `OSPIntensityQuantity`. The supported types of `OSPIntensityQuantity`
@@ -1437,7 +1437,7 @@ specific light source).
   OSP_INTENSITY_QUANTITY_SCALE        a linear scaling factor for light sources with a 
                                       built-in quantity (e.g., `HDRI`, or `sunSky`). 
   ----------------------------------  ----------------------------------------------------
-  : Types of radiative quantities used to interpret a light's `intensity` parameter.
+  : Types of radiometric quantities used to interpret a light's `intensity` parameter.
 
 The following light types are supported by most OSPRay renderers.
 
@@ -1597,7 +1597,7 @@ shadows.
 The HDRI light is a textured light source surrounding the scene and
 illuminating it from infinity. It is created by passing the type string
 "`hdri`" to `ospNewLight`. The values of the HDRI correspond to radiance
-and therfore the HDRI light only accepts `OSP_INTENSITY_QUANTITY_SCALE` 
+and therefore the HDRI light only accepts `OSP_INTENSITY_QUANTITY_SCALE` 
 as `intensityQuantity` parameter value. 
 In addition to the [general parameters](#lights) the HDRI light
 supports the following special parameters:
@@ -1641,9 +1641,9 @@ string "`sunSky`" to `ospNewLight`. The sun-sky light surrounds the
 scene and illuminates it from infinity and can be used for rendering
 outdoor scenes. The radiance values are calculated using the
 Hošek-Wilkie sky model and solar radiance function. The underlying model
-of the sun-sky light returns radiance values and therfore the light
+of the sun-sky light returns radiance values and therefore the light
 only accepts `OSP_INTENSITY_QUANTITY_SCALE` as `intensityQuantity`
-parameter value. To recale the returned radiance of the sky model
+parameter value. To rescale the returned radiance of the sky model
 the default value for the `intensity` parameter is set to `0.025`.
 In addition to the [general parameters](#lights) the
 following special parameters are supported:
@@ -3095,7 +3095,7 @@ through the command line, the following parameters can be set:
 
   uint     commandBufferSize         512\ MiB  Set the max command buffer size
                                                to allow. Units are in MiB. Max
-                                               size is 1.8GiB
+                                               size is 1.8\ GiB
 
   uint     maxInlineDataSize          32\ MiB  Set the max size of an OSPData
                                                which can be inline'd into the
@@ -3122,7 +3122,7 @@ MPI Distributed Rendering
 
 While MPI Offload rendering is used to transparently distribute
 rendering work without requiring modification to the application, MPI
-Distributed rendering is targetted at use of OSPRay within MPI-parallel
+Distributed rendering is targeted at use of OSPRay within MPI-parallel
 applications. The MPI distributed device can be selected by loading the
 `mpi` module, and manually creating and using an instance of the
 `mpiDistributed` device:
@@ -3209,7 +3209,7 @@ occlusion, each rank's data can overlap. To clip these non-owned overlap
 regions out a set of regions (the `region` parameter) can pass as a
 parameter to the `OSPWorld` being rendered. Each rank can specify one or
 more non-overlapping `box3f`'s which bound the portions of its local
-data which it is reponsible for rendering. See the
+data which it is responsible for rendering. See the
 [ospMPIDistributedTutorialStructuredVolume](https://github.com/ospray/ospray/blob/master/modules/mpi/tutorials/ospMPIDistributedTutorialStructuredVolume.cpp)
 for an example.
 

doc/api.md

@@ -29,15 +29,14 @@ before you can build OSPRay you need the following prerequisites:
     `~/Projects/ospray`, ISPC will also be searched in
     `~/Projects/ispc-v1.16.1-linux`.] Alternatively set the CMake
     variable `ISPC_EXECUTABLE` to the location of the ISPC compiler.
-    ISPC 1.16.0 or later is required for Arm support.
 -   OSPRay builds on top of the [Intel oneAPI Rendering Toolkit common
     library (rkcommon)](https://www.github.com/ospray/rkcommon). The
     library provides abstractions for tasking, aligned memory
     allocation, vector math types, among others. For users who also need
     to build rkcommon, we recommend the default the Intel [Threading
     Building Blocks (TBB)](https://www.threadingbuildingblocks.org/) as
     tasking system for performance and flexibility reasons.
-    TBB must be built from source when targetting Arm CPUs, or can
+    TBB must be built from source when targeting ARM CPUs, or can
     be built from source as part of the [superbuild](#cmake-superbuild).
     Alternatively you can set CMake variable `RKCOMMON_TASKING_SYSTEM`
     to `OpenMP` or `Internal`.
@@ -135,7 +134,7 @@ BUILD_OSPRAY_MODULE_MPI
 distributed parallel rendering on multiple nodes.
 
 BUILD_TBB_FROM_SOURCE
-: set to ON to build TBB from source (required for Arm support).
+: set to ON to build TBB from source (required for ARM support).
 The default setting is OFF.
 
 For the full set of options, run:
@@ -171,7 +170,7 @@ CMake is easy:
 
         cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ..
 
-    CMake will now use Clang instead of GCC. If you are ok with using
+    CMake will now use Clang instead of GCC. If you are OK with using
     the default compiler on your system, then simply skip this step.
     Note that the compiler variables cannot be changed after the first
     `cmake` or `ccmake` run.

doc/compilation.md

@@ -17,7 +17,7 @@ We recommend the latest version of both TBB and Embree libraries.
 Packages
 --------
 
-Packages for x86_64 are provided, OSPRay can be built for Arm64/NEON
+Packages for x86_64 are provided, OSPRay can be built for ARM64/NEON
 using the superbuild (see [Building and Finding OSPRay](#building-and-finding-ospray)).
 
 For Linux we provide OSPRay precompiled for 64\ bit as a TGZ archive.  

doc/getting_ospray.md

@@ -20,7 +20,7 @@ OSPRay internally builds on top of [Intel Embree] and [Intel ISPC
 exploits modern instruction sets like Intel SSE4, AVX, AVX2, AVX-512 and NEON
 to achieve high rendering performance, thus a CPU with support for at
 least SSE4.1 is required to run OSPRay on x86_64 architectures.
-A CPU with support for NEON is required to run OSPRay on Arm64 architectures.
+A CPU with support for NEON is required to run OSPRay on ARM64 architectures.
 
 
 OSPRay Support and Contact

doc/overview.md

@@ -244,7 +244,7 @@ case, although the processes are run MPI parallel, each rank specifies
 the exact same data. OSPRay's MPI parallel renderer will detect that the
 data is replicated in this case and use the same image-parallel
 rendering algorithms employed in the MPI offload rendering configuration
-to render the data. This image-parallel rendereing algorithm supports
+to render the data. This image-parallel rendering algorithm supports
 all rendering configurations that are used in local rendering, e.g.,
 path tracing, to provide high-quality images.
 

doc/tutorials.md

@@ -22,5 +22,5 @@ CMake options to note (all have sensible defaults):
 - `BUILD_EMBREE_FROM_SOURCE` set to OFF will download a pre-built version of Embree.
 - `BUILD_OIDN_FROM_SOURCE` set to OFF will download a pre-built version of OpenImageDenoise.
 - `BUILD_OIDN_VERSION` determines which verison of OpenImageDenoise to pull down.
-- `BUILD_TBB_FROM_SOURCE` set to ON to build TBB from source (required for Arm support).
+- `BUILD_TBB_FROM_SOURCE` set to ON to build TBB from source (required for ARM support).
    The default setting is OFF.