---
title: "XPU Features and Limitations"
canonical: "https://rmanwiki-27.pixar.com/space/REN27/542236818/XPU%20Features%20and%20Limitations"
format: markdown
---
> Macro (toc)
With RenderMan 27, for many if not most shots, XPU can be considered a faster, better version of RIS. That being said, there are some areas of work that are still remaining where RIS may still be necessary to render the final shot.
> ℹ️ This icon denotes XPU-only features which are not available in RIS.
- XPU may not converge as well as RIS for shots with many lights, particularly on the CPU. "Many lights" will depend on the scene, but above several hundred lights, RIS will start outperforming XPU.
- XPU will not render certain types of geometry, particularly NURBs and quadrics. For subdivision surfaces, XPU has a completely rewritten geometry engine, and has a more robust subdivision surface implemented based on the OpenSubdiv industry standard. As a result, be aware that some limitations in RIS have been eliminated, which may cause slight image differences.
- XPU's integration with the rest of the studio image pipeline is mostly complete, with a few exceptions. Advanced workflows involving checkpointing and recovery are not finished.
- Until joint sampling is implemented, XPU may have difficulty converging certain scenes with volumetrics, especially ones where the lighting variation in the volume is dominant over the density variation (e.g. crepuscular rays).
- Scenes that require specialized light transport to resolve (manifold walk, bidirectional path tracing, photon mapping, VCM) do not have access to those algorithms when using XPU. The increased speed of XPU may help somewhat, but for e.g. very difficult scenarios such as underwater caustics, RIS with e.g. the PxrVCM integrator may be necessary.
- Baking workflows are not currently supported in XPU; however, baking in RIS and then using the baked results in XPU may be a viable alternative.
---
### General
- The 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. If your scene is too big to fit on the GPU, use the XPUCPU variant instead.
- Multiple GPU rendering is supported; however, we only support configurations where the GPU cards are identical.
- XPU is not yet supported on the Mac, even in CPU mode.
- The performance of GPU renders on scenes with high numbers of transparent objects may be worse than expected. RMAN-23088
- Extremely dense polygon or subdivision surface meshes may incur a higher than expected upfront memory cost to process when compared to RIS. PRMAN-3294
- The behavior of accumOpacity in PxrPathTracer in XPU is somewhat different than in RIS. We believe XPU has the better behavior, and will conform RIS to match in a future dot release. RMAN-23672
---
### DCCS
- In Katana Live Renders, XPU renders aren't respecting the original image origin when overscan is added. This has the effect that the image is correctly resized, but the image appears to be off-center. In addition, when you combine ROI with overscan, the ROI is not in the correct location. RMAN-24144
---
### Shading
| **BxDFs, Displacement & Patterns** | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| PxrSurface | ✅ | ✅ | See below for list of unsupported features in PxrSurface |
| PxrLayerSurface | ✅ | ✅ | |
| PxrDisneyBsdf | ✅ | ✅ | |
| PxrMarschnerHair | ✅ | ✅ | |
| PxrConstant | ✅ | ✅ | |
| Lama | ✅ | ✅ | See the MaterialX Lama section below for details. |
| Volumes | ✅ | ✅ | Only supported for aggregate volumes. |
| OSL Patterns | ✅ | ✅ | See OSL section for further details. |
| C++ Patterns | ✅ | ❌ | XPU has no plans to support C++ patterns. |
| Baking | ✅ | ❌ | |
| Point Clouds | ✅ | ❗ | CPU support only for now; GPU support expected soon. |
- Custom Bxdf or Displacement plugins will not be supported in XPU.
- Due to differences in how XPU computes derivatives for normals, XPU may compute different results from RIS for bump-mapped subdivision surfaces in areas of highly concave curvature, combined with a high bump scale. This happens especially when the bump mapping cannot reasonably approximate the displacement. Note that this difference does not occur with displacement. The issue can be ameliorated by reducing the bump scale. **This issue has been addressed in 27.4.**
- Because dynamic arrays are not supported at the Bxdf level, only one input userColor is currently supported.
- The following functionality is currently not supported in PxrSurface:
- certain subsurface types (Jensen Dipole, D'Eon Better Dipole, PBS Burley Normalized, Multiple Mean Free Paths)
- subsurfaceDiffuseSwitch - will not be implemented. As an alternative, set subsurfaceDmfp to 0 or subsurfaceDmfpColor to 0
- subsurface considerBackside
- singlescatterMaxContinuationHits
- irradianceTint - partially implemented; in XPU, tint is evaluated at light exit point, in RIS it is evaluated at light entry point
- scattering irradianceRoughness
- glassRefraction2Roughness, glassRefraction2Blend
- glassAnisotropyDirection
- manifold walk (mwWalkable, mwIor)
- roughnessMollificationClamp
---
### MaterialX Lama
#### Base nodes
- All MaterialX Lama base nodes are supported with the exception of LamaTriColorSSS, which currently does not exist in XPU. RMAN-23971
- The lobeName, userLobeName, matte parameters (and other parameters of this type) are not currently supported in the Lama leaf nodes - the Lama nodes will only write to the default lobe values (e.g. lower case “diffuse”, “specular”, etc). This may affect certain pipelines especially around the use of the denoiser. This will be addressed in a dot release. RMAN-22926, RMAN-24093
- LamaSSS node, when used with LamaAdd or LamaMix, may cause the other node to be weighted too high. The effect is that the illumination may be slightly too bright. This will be fixed in a dot release. RMAN-24240
- The LamaSSS subset parameters do not work correctly when the node is used inside a combiner. RMAN-24421
- LamaDielectric’s dispersion does not work correctly when the node is used with LamaSurface. RMAN-24431
- The LamaIridescence node currently does not support the targetHue_Knots, targetHue_Colors, incidentAngle_Knots, and incidentAngle_Floats parameters due to missing support for dynamic arrays in XPU. RMAN-22910
- Volumetric scattering in Lama may not match RIS on inside out or non-closed surfaces. This is a general issue with other shaders in XPU as well. RMAN-24146
- Lama shaders attached to nested materials will not correctly compute the index of refraction relative to each other. This is also a problem in RIS, although the manifestation of the problem differs. RMAN-22847
- :xpuonly: XPU’s support for the absorption/extinction behavior of LamaDielectric and LamaGeneralizedSchlick goes beyond what RIS is capable of: XPU will correctly combine the single scattering lobes in all situations, even if it means the single scattering ends up being varying across the material because of the combiner (e.g. due to a varying mix weight in LamaMix). (Note that this is an artist friendly, but non-physical effect: a single ray that enters the material will retain the same single scattering coefficients for the entire duration of its traversal beneath the surface; but *across multiple rays* that enter the material, XPU now allows each ray to have different single scattering coefficients.) Version 27.3 allows absorptionColor and absorptionRadius to be varying connections on these two nodes, which is a capability not supported in RIS.
#### Combiner Nodes
- LamaAdd and LamaMix are fully supported. There may be some issues with specific base nodes when used in conjunction with LamaAdd and LamaMix as noted above.
- LamaSurface is fully supported.
- XPU ignores the presenceCached parameter on LamaSurface, because there is no presence or opacity caching in XPU. Please note this when comparing surfaces involving transparent objects with RIS, as RIS’ behavior for shadows and interiors changes with this parameter. For valid comparisons, you should turn off presenceCached in RIS.
- There may be a discrepancy in IOR/refraction behavior between RIS and XPU on LamaSurface when refractive materials are plugged into both the front and back. RMAN-24248
- LamaLayer is fully supported. There may be some issues with specific base nodes when used in conjunction with LamaLayer:
- Thin shadows cast by LamaLayer (e.g. when a dielectric is layered with diffuse) may be wrong in certain cases. RMAN-24243
- A dielectric layered on top of a dielectric in LamaLayer may produce slightly different refraction or reflection results from RIS depending on the roughness. RMAN-24250
- Interior aggregate volumes will be shut off in a Lama combiner network. RMAN-23831
---
### MaterialX
:xpuonly: XPU provides native support for MaterialX [BSDF](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#bsdf-nodes), [EDF](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#edf-nodes) and [combiner nodes](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#utility-nodes), enabling support for arbitrary MaterialX shading networks directly within the renderer. This allows artists to render MaterialX materials using both CPU and GPU rendering workflows without relying on translation to [PxrSurface](https://rmanwiki-27.pixar.com/space/REN27/542213836) (which is required when using RIS). This also means XPU should provide a more representative result compared to RIS; in particular, MaterialX material layering is fully supported in XPU, whereas it is not supported in RIS.
It is important to note that native MaterialX BSDF and combiner support in XPU is currently available through RenderMan's Hydra integration and USD workflows, and is presently supported in Solaris-based pipelines.
There are still a small number of MaterialX features that are not yet supported in RenderMan:
- Only the [uniform_edf](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#uniform_edf) node is currently supported. Other EDF nodes are not yet available.
- MaterialX [VDF](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#vdf-nodes) nodes are not currently supported. Support for volumetric shading nodes is planned for a future release.
- MaterialX [PBR shader nodes](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#pbr-shader-nodes) used directly as surface shaders are not currently supported.
---
### Patterns & Textures
- There is no support for custom C++ plugins. Patterns written in OSL are supported.
- PxrSeExpr is not supported (and will likely never be supported).
- Point clouds are currently only supported on the CPU; GPU support is forthcoming.
- PxrBakeTexture and PxrBakePointCloud are not supported.
- PxrSwitch is not supported.
---
### Volumes
- In XPU, the expected workflow for heterogeneous volumes is via aggregate volumes. XPU has limited support for the non-aggregate volume workflow: only homogeneous volumes are supported, via the glass single scattering functionality in PxrSurface, PxrVolume, LamaGeneralizedSchlick and LamaDielectric.
- :xpuonly: In 27.3, PxrSurface, LamaGeneralizedSchlick and LamaDielectric support connections on the extinction or absorptionColor parameters; however, these are not physically accurate heterogeneous volumes, because the density property only varies *across* the rays when they enter the glass, not *along* the rays. Nonetheless this can be a artistically useful effect which is much cheaper than a full heterogeneous volume.
- XPU fully supports volume primitives of type "box" and "blobbydso" (ImplicitField plugins); however, VDB volumes are the optimized preferred choice, and non-VDB volumes will incur a cost for upfront internal conversion to VDB.
- Glass single scattering support in PxrSurface is mostly complete in XPU, but there may be differences in behavior from RIS when it comes to certain cases. In particular, intermixing objects with homogeneous single scattering and aggregate volume primitives may not lead to identical results with RIS.
- Deformation motion blur via velocity is supported, but currently requires specification of the velocity grid directly to `impl_openvdb.so` as the third string parameter; or, starting in 27.3, XPU will also support the `velocityPrimVar` parameter to PxrVolume. Arbitrary shading for velocity (via the `velocity` parameter of PxrVolume) is not supported. We anticipate lifting some of these restrictions in a future release.
- Joint sampling is not yet supported, so the convergence of volumes with complicated lighting that requires joint sampling will not be as performant as RIS on a per-sample basis.
- :xpuonly: In 27.3, setting the "Volume Guiding" in PxrPathTracer to "Oversample Volumes" can improves the convergence of thin volumes substantially and has minimal overhead, especially when rendering volumes on their own layer. Enabling "Oversample Volumes" in mixed volume/surface layers is supported but it will increase noise from the surface and may not benefit overall convergence.
- Instancing of volumes is not fully supported. PRMAN-3643. **This limitation has been lifted in 27.4.**
---
### OSL
- :xpuonly: XPU will freely allow conversions from float to int and vice versa and from `float[3]` to `color` and `point` types when performing lookups using `getattribute()`, and the call will return 1. RIS does not allow this conversion and returns 0.
- XPU supports a large subset of the RIS `getattribute()` functionality:
- `getattribute("lpe:match")` and `getattribute("lpe:throughput")` is fully supported
- `getattribute("rendererInfo")` is fully supported
- `getattribute("context")` is fully supported (however, note that some queries, like `"eyePath"/"lightPath"/"missContext"`, never change answers in XPU due to lack of bidirectional support or features that will not be implemented)
- `getattribute("global")` is supported (including looking up user options), but note that many Options in RIS are no longer meaningful in XPU and cannot be looked up.
- `getattribute("attribute")` is supported, but *only* for looking up user attributes at the current time.
- `getattribute("primvar")` is supported. This includes the behavior that user attributes bound to the instance with the queried name will be returned, but only if there is no primvar with that name bound to the prototype.
- `getattribute("builtin")` is a special case in XPU. Some lookups available in RIS are not 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 an OSL global exists. Also, note that technically the difference between "builtin" and "primvar" is non-existent in XPU, i.e., most of these so-called “builtins” are actually primvars in XPU (with the exception of "id").
| **Builtin** | ** XPU Support** | **Notes** |
| --- | --- | --- |
| 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 | ✅ | |
| time | ❌ | use global time |
| id, id2 | ✅ | |
- `raytype()` is not supported. The `getattribute("lpematch"/"context", ...)` calls may substitute for some of this functionality.
- `trace()` is supported. Like RIS, XPU does not support `trace()` calls from displacement, and does not support recursive tracing, so the `"shade"` parameter is ignored (it is treated as having a value of 0). `getmessage("trace", ...)` can be used in conjunction with successful `trace()` calls to query certain results from hit geometry: `"P", "Ng", "hitdist"` can be used to retrieve the point, the normal, and the distance to the hit respectively. `"hit"` is an integer valued query that is supported and has value 0 or 1 depending on whether geometry was successfully hit. `"geom:name"` is not currently supported, but interpolated vertex variables attached to the hit geometry can be retrieved, with the restriction that for strings, only constant class variables are supported.
- `texture3d()` point cloud support is currently only supported on CPU, with GPU support expected in a future point 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.
- Dynamic path construction in your own patterns is not supported, but please note that we **do** support the following path tokens , , , , , and that will result in a "dynamic" path to your textures. can be used to reference the value in a constant primvar or user attribute to build a dynamic path
---
### Geometry
| | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| Subdivision Surfaces | ✅ | ✅ | Catmull-Clark only. Loop will not be supported since OpenSubdiv has dropped support. |
| Polygonal Surfaces | ✅ | ✅ | |
| NURBS | ✅ | ❌ | XPU has no plans to support NURBs in the future. |
| Curves | ✅ | ✅ | |
| Points | ✅ | ✅ | Falloff may be inconsistent with RIS. |
| Quadrics and Blobbies | ✅ | ❌ | Spheres may be supported in a future release, but there are no plans for other quadrics or blobbies. |
| Procedurals | ✅ | ❌ | |
| Nested Instancing | ✅ | ✅ | Only 4 levels of instancing are supported. Material and attribute overrides are fully supported. |
| Nested Dielectrics | ✅ | ✅ | XPU does not fully support intersectpriority. |
| Dicing cameras | ✅ | ✅ | |
| Watertight tessellation | ✅ | ✅ | Watertight tessellation is always enabled in XPU, and cannot be opted out of |
| Watertight displacement | ❌ | ✅ | Displacement is always watertight in XPU, and cannot be opted out of |
- Loop Subdivision is not supported. Catmull-Clark for both quads and triangles **is** supported.
- Point falloff is not fully supported.
- Inverted normals are possible when doing displacement, depending on the input file and DCC. We have seen this with Alembic being imported into Houdini. We have also seen this in certain motion-blurred subdivision cases.
- XPU supports the correct recovery of "outside IOR" on nested dielectrics with Attribute "trace" "intersectpriority", but does not currently handle phantom hits (skipping geometry when the intersectpriority is lower). **This limitation has been lifted in 27.4.**
- The curvature calculation on extraordinary subdivision mesh vertices (such as those arising from triangular Catmull-Clark meshes) does not match RIS. This may cause illumination differences when deep specular bounces are combined with roughness mollification.
- Extremely dense subdivision meshes may consume larger amounts of memory on initial ingestion, possibly leading to OOM on high thread counts. This will be addressed in a 27 point release.
---
### Lighting
| | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| Analytic Lights | ✅ | ✅ | |
| Mesh Lights | ✅ | ✅ | Not yet supported in XPU for volumes.
XPU supports mesh lights on points. |
| Light Filters | ✅ | ✅ | |
| Light Linking | ✅ | ✅ | |
| Scalability to many lights | ✅ | ❌ | Past a certain threshold, XPU's convergence performance will decrease compared to RIS. |
- XPU does not support manifold next event estimation.
- :xpuonly: Unlike RIS, deformation blur and transformation blur should work correctly with XPU mesh lights. As a result, there may be some lighting differences with scenes containing such lights.
- :xpuonly: XPU supports the use of points as mesh lights.
---
### Integration & Ray Tracing
| | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| PxrPathTracer | ✅ | ✅ | - Various supersampling controls are not supported, including:
- sampleMode, and the related manual sampling controls numDiffuseSamples, numSpecularSamples, numSubsurfaceSamples, numRefractionSamples
- numBxdfSamples
- numVolumeAggregateSamples
- numIndirectSamples
- Non-stochastic presence is not currently supported - the maxNonStochasticOpacityEvents parameter is ignored.
- XPU's implementation of Russian Roulette differs from RIS
- Joint sampling controls for volumes are not supported |
| PxrUnified | ✅ | ❌ | |
| PxrVisualizer | ✅ | ✅ | - shadedPrimVar is not supported
- matCap is not supported |
| PxrDefault | ✅ | ✅ | |
| Trace Sets | ✅ | ✅ | |
| PxrVCM | ✅ | ❌ | |
- Hider … “int samplemotion” [0] is not currently supported in XPU. This means support for 2D motion vector output from XPU is not working correctly, as the geometry will remain blurred. RMAN-22362
---
### Displays and Pipeline
| | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| Denoising | ✅ | ✅ | All LPEs required for denoising are supported by XPU |
| Sample Filters | ✅ | ✅ | XPU supports OSL sample filters and OSL pattern inputs.
The PxrImagePlaneFilter and PxrWatermarkFilter are not yet supported. |
| Display Filters | ✅ | ✅ | XPU supports OSL display filters and OSL pattern inputs.
The PxrImageDisplayFilter is not yet supported. |
| Interactive Denoiser | ✅ | ✅ | |
| Crop Windows | ✅ | ✅ | |
| AOVs and LPEs | ✅ | ✅ | |
| EXR, TIFF | ✅ | ✅ | |
| Deep Output | ✅ | ✅ | XPU has support for native DeepEXR Ids.
XPU currently does not output volume segments. |
| Matte and Holdouts | ✅ | ✅ | XPU does not support special __illumholdout light groups. |
| Advanced DOF controls (bokeh, etc) | ✅ | ✅ | |
| Checkpointing | ✅ | ✅ | |
| Recovery | ✅ | ❌ | |
- In versions prior to 27.3, XPU currently only outputs EXR or TIFF frames.
- XPU only supports deep output via the DeepEXR driver; it will not support the legacy Pixar Deep Shadow format.
- XPU supports OSL sample and display filters; it does not support C++ plugins. For display filters, API equivalents to Read, ReadRegion and Write are available via OSL:
- Read equivalent: `texture(AOVName, u, v)`;
- ReadRegion equivalent: `texture(AOVName, x, y, "subimage", 1)`;
- Write equivalent: `Ci += debug(AOVName) * rgb`;
- XPU supports sample filters partially. Read and Write are supported, while ReadRegion, primvar access and trace() from sample filters are not yet supported.
- Only some geometric built-in AOVs are available under the same name as they are available for RIS. For example, among others, __Pworld, __Nworld, and __depth are not available.
- Multi-camera, multi-frame 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).
- User lobes are currently not subject to clamping by the integrators.
---
### Projection Plugins
| | **RIS** | **XPU** | **Notes** |
| --- | --- | --- | --- |
| PxrPerspective | ✅ | ✅ | |
| PxrOrthographic | ✅ | ✅ | |
| PxrCamera | ✅ | ✅ | Matte, shutter direction/sweep and Circle of confusion texture not yet supported in XPU |
| PxrLightProbe | ✅ | ❌ | |
| PxrPanini | ✅ | ❌ | |
| Omnidirectional Stereo | ✅ | ❌ | |
| PxrSphereCamera | ✅ | ✅ | |