It is inevitable to make rendering and performance comparisons between RenderMan XPU™ and RenderMan RIS.  Please do so with caution because of all of the known limitations listed below.  In this look development focused release of RenderMan XPU, we expect that its renders will be predictive of RIS.  We are going to do our best to make it match as accurate as possible (but not guaranteeing a 100% pixel for pixel match), but because of the limitations of XPU, there will inevitably be differences.  The differences in look can then impact performance.  So be careful when comparing the performance of XPU to RIS – you may inadvertently be giving a performance advantage to one over the other if you're not careful.  XPU vs RIS performance numbers are very difficult to compare quantitatively.

While it is an interesting exercise to try to achieve pixel parity between XPU and RIS, please do so with caution.  In most cases, if you embark upon this road, you will be "dumbing down" your RIS renders.  RIS has several performance optimizations (such as the ability to control the maximum recursion depth for diffuse and specular bounces independently), XPU does not have these knobs.   These help RIS' performance, and turning them to the values that give an equivalent look to RIS can make RIS artificially slower.  As XPU evolves, it will receive the same kinds of optimizations that will allow for more direct comparison between the two renderers.  But they aren't in XPU yet.

Known XPU Limitations and Rendering Differences Compared to RIS

...

Before we dive in to the list of differences and limitations, a word is necessary about performance.  The performance of the GPU vs the CPU is difficult to quantify and discuss.  The best we can say is that the performance of XPU exceeds RIS.  How much faster it is than RIS, and how much faster the GPU side is compared to the CPU side is governed by money – the more you spend on a particular component, the better it will perform compared to the other.  Please see the Comparing XPU to RIS section below for details.

In general, we recommend a large amount of RAM, both on the CPU side and the GPU side.  Due to the constrained memory on GPUs, the more memory you have here is especially important.

...

• Stylized Looks
• BxDFs
  • Lama.  Lama is not yet available for XPU
  • PxrSurface is supported, but there are a few edge cases that are not.
    • subsurfaceSubset is not supported
• Color Management
  
  • XPU does not support color temperature on lights yet, so we cannot apply the right color space when converting a temperature to an RGB value
• Geometry
  • Facesets.  Facesets for shading are not supported.
  • Loop Subdivision.  Catmull-Clark is supported
  • Points.  Have been partially implemented.  Point falloff is not yet supported.
  • NURBS
  • Quadrics
  • Blobbies
  • The built-in curvature doesn't match RIS and will be receiving enhancements in a future release
  • Nested instancing
• Ray Tracing
  
  • Motion blur has not been fully implemented
  • Trace Subsets have not been implemented.  This then impacts the subsurfaceSubset feature of PxrSurface
• Textures
  • Dynamic path construction in your own patterns is not supported, but please note that we do support the following path tokens <UDIM>, <u>, <v>, <U>, <V> and <primstr:varname> that will result in a "dynamic" path to your textures.  <primstr:varname> can be used to reference the value in a constant primvar or user attribute to build a dynamic path.  Also note that <primstr:varname> is not in beta1 for XPU, but will be in a later beta.
  • XPU samples textures at one MIP level coarser than RIS so that it may store more textures in limited GPU memory.  This results in slightly blurrier renders from XPU than RIS.
• Patterns
  • Dynamic String construction in your own patterns is not supported
  • PxrSeExpr not supported
  • trace() OSL call is not yet supported.  In the future when it is implemented, it will only support one level of recursion.
  • Point clouds not supported
  • PxrBakeTexture and PxrBakePointCloud not supported
  • Transformations between color spaces spaces are ignored
• Lighting
  • Light Filters
  • Light Linking
  • "shot" oriented Lighting features.  Examples include:
    
    • Visible in Refraction Paths
    • Emission Focus
    • Light groups
    • Manifold Next Event Estimation
  • Thin shadows
  • Mesh lights
  • Color temperature
  • Cylinder Light
  • PxrEnvDaylight
  • Large numbers of lights.  XPU does not have a light selection scheme that allows it to scale to large number of lights.
• Volumes
• User defined AOVs or LPEs
  • Only some geometric built-in AOVs are available under the same name they are available for RIS.
• Integrator restrictions
  • numBxdfSamples, numLightSamples, numIndirectSamples (and their manually set counterparts)
  • clampDepth and clampLuminance have not been implemented as a way to supress fireflies
  • Russian Roulette has not been implemented
  • allowCaustics is always 1
• Adaptive sampling
• Baking - either at the pattern level via PxrBakeTexture or at the renderer level to bake global illumination
• Object attributes
  • maxdiffusedepth
  • maxspeculardepth
• The built-in curvature calculation different is different to RIS, which results in differences in specular mollification.
• GPU required, even if all you are doing is CPU rendering
• Thread count limits on startup not respected
• Display filters
• Sample filters (which means that Cryptomatte is not yet supported)
• The "weighted" option for the pixelfiltermode parameter to the Hider
• Procedurals not supported.  However, if you are using the latest XGen in Maya, you should get renders of your data.
• Image output - only EXR and TIFF
• Plugins for BxDFs, Integrators, RtxPlugin for dynamic textures, etc.
• Holdouts, shadow collectors
• Deep Output
• Multi-camera, multi-frame
• PxrOcclusion, PxrVisualizer, PxrUnified
• macOS not supported.

...

Validating XPU

...

renders with RIS

Below is the list of items that you need to do to more accurately compare XPU to RIS.  Even if you perform all of the actions below, it won't get you a 100% match between XPU and RIS, but it will get you closeXPU produces renders that are predictive of RIS.  However, there are features in RIS that don't exist in XPU yet.  Some of these features are the reason why your XPU images may differ slightly from RIS.  If you find yourself in the situation where you need to validate the results you see in XPU using RIS, use the hints below to make your RIS renders achieve that comparison.  However, if tweak these knobs, be aware you may be artificially slowing down RIS, so proceed with caution.

• Sample count - XPU does not yet support adaptive sampling, so you must be sure to disable it
  • minsamples = maxsamples - To ensure that XPU and RIS are sampling at similar rates, you need to make sure that you have disabled adaptive sampling via the easiest mechanism - to set the minsamples setting equal to the maxsamples setting.
    
    
• Ray depths - Make sure your ray depths are equivalent.  If you don't do this, you'll be giving unfair advantage to RIS because XPU does not yet support several options that RIS provides to limit ray depths.  Limiting ray depths is one of the primary ways in RIS to get better performance.
  
  • maxIndirectBounces - This is the only knob in XPU to control ray depth.
  • maxdiffusedepth and maxspeculardepth - These are object attributes used to control how many diffuse and specular bounces RenderMan should descend into as it traces.  It is one of the knobs that you can use to trade look for performance.  XPU does not support these.  So for your RIS render, be sure that you have set these object attributes to a number higher than maxIndirectBounces on the Integrator or else you will be giving RIS an unfair advantage.  In this way, the control on the Integrator will control the ray depth.
    
    
• Other Integrator controls.
  • numLightSamples, numBxdfSamples, numIndrectSamples (and their companions when you're in "manual" mode).  XPU does not support these.  XPU takes only one sample for each category per iteration.  If your settings are higher than 1 for any of these, you will be giving an unfair advantage to XPU because RIS will be doing extra work.
  • rouletteDepth, rouletteThreshold.  XPU does not support Russian Roulette yet, so be sure to set the rouletteDepth to a sufficiently high value beyond the maxIndirectBounces so that RIS does not start cutting off ray paths that XPU would be tracing.
  • clampDepth, clampLuminance.  XPU does not yet support illumination clamping, so be sure to set clampDepth and clampLuminance to a sufficiently high value beyond the maxIndirectBounces so that RIS does not start cutting off ray paths that XPU would be tracing.
  • allowCaustics.  RIS defaults this to 'off'.  But XPU doesn't yet have the facilities to support the mechanism required to cut off caustics.  So set this to 'on' for RIS.
    
    
• Light settings.
  • "int traceLightPaths" 1. This needs to be 1 in order for RIS to more closely match XPU
    
    
• Specular mollification settings.
  • Option “shade” “roughnessmollification” 0.0  (default is 1.0).  XPU has not yet fully implemented built-in curvature, so it's specular mollification capabilities are not quite as capable as RIS yet.  By setting this to 0.0 in RIS, you will bring the renders closer together, but they will still be somewhat different.
    
    
• Eliminate any usage of "shot" lighting features, such as light linking, light filters, or the light controls that give more nuance.
  
  
• Be aware of the other XPU limitations described above and eliminate as many of them as possible from your test.

...