Below is a list of features supported and unsupported in this phase one release of XPU

General

• XPU currently requires a CUDA-compatible GPU to be installed, even if the intention is to run only in CPU mode.
• Behavior of XPU when it runs out of memory on your GPU:  XPU will crash if it runs out of memory on your GPU.  If you are running XPU inside of Maya, Houdini, or Blender, this will bring down your application as well.  Be sure to save often.  We are going to work to mitigate the two biggest causes of this condition.
• If you have more than one GPU, we allow you to specify which GPU to use with XPU, but do not yet support the ability to use more than one GPU at the same time.
• Releasing a license:  It is possible to get XPU into a situation where it doesn't release the license back to the RenderMan license server.  If this happens and you end up using all of your licenses, just restart your application (Maya, Houdini, Katana, or Blender) and you will be able to continue your work.

DCCS

• XPU does not currently support redirection of errors away from the console, which means DCCs will not be able to report XPU errors in their UI.
• Warnings on the console when rendering to XPU from Katana.  There are some warnings you will see on the console about a bad DSO being found for the socket display driver.  You can ignore these.
• Picking from "it" does not relay the selection back to RenderMan for Maya
• RenderMan for Maya supports batch rendering to XPU (PxrPathTracer integrator)

Shading

• Custom Bxdf or Displacement plugins are unsupported.
• MaterialX Lama support will be implemented in a future release.
• In XPU, we support the following SSS models:
  • Burley Normalized
  • Exponential Path Traced
  • Non-Exponential Path Traced
• subsurfaceSubset is not yet supported.
• Single scattering support in PxrSurface is not complete because volumetric light transport is not fully supported in XPU.

Patterns & Textures

• There is no support for custom C++ plugins. Patterns written in OSL are supported.
• PxrSeExpr is not supported.
• PxrDirt & PxrCurvature require the trace() OSL call, which is not yet supported.
  
• Point clouds are not supported.
• PxrBakeTexture and PxrBakePointCloud are not supported.
• 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.

• We are currently in the process of updating the texture cache for the GPU to give better performance if it isn't large enough to hold the textures required for your render.

• Textures with a non square pixel aspect ratio are not supported.
• If you update a texture while the renderer is running, XPU may not update the texture. If this happens, restart your render.
• If you stop interactive rendering while textures are still being made, sometimes you will get a crash.

OSL

• In XPU, the first argument to the OSL getbuiltin() shadeop is ignored. You may continue to specify a first argument in order for your shader to remain compatible with RIS, but the distinction between "primvar", "builtin", and "attribute" that exists in RIS does not exist in XPU.
• getattribute() calls asking for geometry primvars (in RIS, getattribute("primvar")) are fully supported.

• getattribute() calls targeting "builtins" (renderer computed quantities that are not directly geometry primvars) are partially supported. Some builtins known to RIS are not currently available in XPU. The most important changes are summarized in the table below. If an alternative is suggested, it means that OSL patterns should be rewritten to use the alternative to be as forward looking as possible, particularly if a OSL global exists.

  Builtin	Supported in XPU	Alternative (if possible)
  P	✅	global P may be preferred
  PRadius	❌	use filterwidth() (scaled to radius if needed)
  Po	✅
  Nn	❌	use global N
  Non	✅	supported, but only if displacement took place
  Ngn	❌	use global Ng
  Naon	❌	point Po; getattribute("primvar", "P", Po); Naon = normalize(cross(Dx(Po), Dy(Po)));
  Tn	✅
  Vn, VLen	❌	derive from global I: Vn = -normalize(I); VLen = length(I);
  curvature	❌
  dPdu, dPdv	❌	use globals dPdu and dPdv
  u, v	✅	globals u and v may be preferred
  st	✅
  du, dv	❌	use 0.5 * Dx(u), 0.5 * Dy(v)
  dPdtime	❌	use global dPdtime, but currently hardcoded to (0, 0, 0)
  time	❌	use global time
  id, id2	✅

• The only getattribute("attribute", ...) lookups that are supported in XPU are "user" attributes (e.g. getattribute("attribute", "user:foo", foo)).
• getattribute("context") and getattribute("rendererInfo") queries are not supported in XPU.
• trace() is not currently supported. Support for a single level of recursion will be added in a future release.
• Dynamic string construction is not supported.
• It is possible in some cases that strings within OSL patterns are not properly constant folded, resulting in errors at runtime.

Known XPU Limitations and Rendering Differences Compared to RIS

This first release of RenderMan XPU™ is targeted for interactive look development on an artist desktop.  While you can likely use it to put renders on the farm in batch mode, that isn't the primary use case for this release.  Because this first release is meant for look development, it does not include several features that you would need for shot lighting.  Rather than waiting for XPU to have every feature of RenderMan RIS before releasing it, we want to give our commercial customers the ability to have their artists be more creative because of the reduced iteration time and improved performance, and at the same time allowing them to reach their creative goals more rapidly – also because of the improved performance.

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.

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.

Below is the list of items that XPU does not support compared to RIS.

• 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 (this feature will be available 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
• 24.1)

...

Lighting

• Light Filters & Light Linking are currently not supported.
• "shot" based lighting features will be available in future releases.  Examples include: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

XPU 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.

• are currently not implemented.
•  XPU does not support color temperature on lights yet. This means the correct color space won’t be applied when a temperature is converted to an RGB value.
• VIRP (visible in refraction path) is not implemented (among other things, it requires LPE support).
  

...

Geometry

• Loop Subdivision is not supported. Catmull-Clark for both quads and triangles is supported.
• Point falloff is not yet supported.
• Object attributes such as maxdiffusedepth and maxspeculardepth have not yet been implemented.
• Deformation motion blur is not yet supported.

• Shading of nested instancing has artifacts.  In our tests we have seen shading issues with leaves that are rendered as nested instances.

• Inverted normals are possible when doing displacement, depending on the input file and DCC.  We have seen this with Alembic being imported into Houdini.

• String and matrix geometry primvars are not supported.

...

Integrators

• numBxdfSamples, numLightSamples, numIndirectSamples (and their manually set counterparts) are not supported.
• clampDepth and clampLuminance (used to suppress fireflies) have not been implemented.
• Russian Roulette has not been implemented.
• allowCaustics is always 1.
• Non-stochastic presence is not currently supported - the maxNonStochasticOpacityEvents parameter is ignored

...

Rendering

• XPU currently only outputs EXR or TIFF frames.
• Adaptive sampling is yet to be implemented.
• Motion blur has not been fully implemented. Transformation motion blur is fully functional, but deformation motion blur of geometry is not supported.
• Trace Subsets have not been implemented.  This impacts the subsurfaceSubset feature of PxrSurface.
• Only some geometric built-in AOVs are available under the same name as they are available for RIS.
• Multi-camera, multi-frame is not yet supported.
• The built-in curvature calculation is different to RIS, which results in differences in specular mollification.
• The "weighted" option for the pixelfiltermode parameter to the Hider is not yet supported.
• Baking - either at the pattern level via PxrBakeTexture or at the renderer level to bake global illumination is not yet supported.
• Cached presence or opacity is not supported in XPU. XPU renders of transparent surfaces may be sharper as a result (they will not be biased by the micropolygon size)Sample count - XPU does not yet support adaptive sampling, so you must be sure to disable itminsamples = 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.