For those who don’t know the tool: RenderMan from Pixar is a production renderer used across VFX and animation. It integrates with basically all DCC apps and USD pipelines.

Pixar has released RenderMan 27.2, the latest update to its production rendering system. According to the official documentation and release notes, the update focuses on improvements to USD workflows, XPU rendering, and core stability. RenderMan is developed by Pixar and is used in feature animation and VFX production. The 27.2 release follows the established 27 series architecture.

USD and Hydra workflow updates

RenderMan 27.2 continues to refine its USD centric rendering path. USD serves as the backbone for scene descriptions in many production pipelines, and RenderMan’s Hydra delegate enables interactive and final-frame rendering of USD stages within host applications. The update includes adjustments to how USD stages are translated and synchronised. Changes affect the evaluation and propagation of attributes from USD primitives into RenderMan’s internal scene representation. This includes refinements to light, material and geometry handling when rendering directly from USD.

Behaviour between Hydra-driven rendering and traditional scene translation paths has been aligned in several areas. Parameter evaluation and state updates have been corrected to reduce discrepancies between USD and non-USD workflows. OpenPBR support is extended within USD contexts. OpenPBR is an open material model designed for renderer-agnostic material definition. RenderMan 27.2 improves the mapping and interpretation of OpenPBR parameters, ensuring more consistent shading results when using USD-defined materials.

Light handling in USD scenes has been refined, including updates to parameter interpretation and light linking behaviour. Attribute inheritance and override cases have also been corrected in specific scenarios.

XPU feature coverage expands

RenderMan XPU, Pixar’s hybrid CPU GPU rendering architecture, receives additional feature support in 27.2. XPU is designed to distribute rendering workloads across CPU and GPU devices in a single render session. In earlier 27.x builds, some shading nodes and features were restricted to RIS, the CPU based renderer. The 27.2 update brings further parity between RIS and XPU.

Additional shading nodes and material features are now supported in XPU. Parameter handling and default values have been aligned more closely with RIS, reducing behavioural differences between the two modes. Updates also affect integrator behaviour and light transport handling in XPU. Certain light types and rendering options now behave consistently across CPU and hybrid modes. Texture evaluation and displacement workflows have been corrected in XPU, addressing cases where results diverged from RIS. This includes fixes to shading artefacts and inconsistencies in displacement evaluation under specific configurations.

Shading system refinements

RenderMan 27.2 introduces updates across its shading and material system. Changes affect specific shader nodes, parameter ranges and default values. In several cases, adjustments were made to ensure consistent evaluation between RIS and XPU.

OpenPBR integration continues to evolve, with improved correspondence between OpenPBR inputs and RenderMan’s internal shading representation. This reduces mismatches when exchanging materials through USD based pipelines.

Layered material evaluation has been corrected in edge cases involving texture lookups and attribute overrides. Procedural shading nodes receive fixes addressing order of operations and attribute inheritance issues. Arbitrary Output Variables, or AOVs, are also affected. The update corrects output behaviour in certain configurations, ensuring that custom render passes produce the expected data for compositing workflows.

Geometry and motion updates

Geometry handling has been refined in 27.2. Subdivision surface evaluation has been corrected in specific cases, particularly when driven by USD scene data. Instancing behaviour and attribute propagation across instances have also been updated to ensure accurate rendering results.

Motion blur evaluation receives fixes addressing timing and interpolation of animated attributes. These corrections affect both geometry deformation and transformation blur under certain configurations. Displacement workflows have been adjusted, improving consistency in how displacement is evaluated across rendering modes. This reduces visible discrepancies between CPU and hybrid renders.

Volume rendering and lights

Volume rendering receives targeted corrections in sampling and shading behaviour. These address edge cases that previously resulted in artefacts or incorrect density evaluation in particular setups. Lighting workflows are refined in both USD and non USD contexts. Light parameter interpretation, linking and shadow behaviour have been corrected where inconsistencies were identified. These changes contribute to more predictable lighting results when switching between RIS and XPU or between traditional and USD based scene translation.

Incremental

RenderMan 27.2 is an incremental update focused on expanding USD and XPU coverage, aligning behaviour between rendering modes, and correcting shading, geometry and lighting edge cases. There are no architectural overhauls in this release. Instead, the emphasis is on feature parity, correctness and stability across established workflows.

Facilities relying on USD centric pipelines or actively deploying XPU will find broader feature support and fewer fallback scenarios. As always, new tools and innovations should be tested before use in production.

// RenderMan 27.2 documentation
// https://rmanwiki-27.pixar.com/space/REN27/726761480/RenderMan+27.2/

The post RenderMan 27.2 adds USD and XPU updates first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: MoonRay is DreamWorks Animation’s in-house Monte Carlo path tracer, open-sourced in 2023 under Apache 2.0. It drives DreamWorks’ film rendering pipeline and supports hybrid CPU/GPU (XPU) modes. MoonRay integrates with DCCs via its Hydra delegate (hdMoonRay) for tools such as Houdini and Katana. The project includes the Arras framework for distributed rendering and collaboration across clusters.

Light Path Visualiser Enters the Scene

The new light path visualiser in moonray_gui is the most visible change in version 2.34.0.1. It lets artists trace how rays travel through a scene, showing how light interacts with surfaces, volumes, and materials. The visualisation is colour-coded by ray type and can reveal sampling or shading inconsistencies that are otherwise invisible. It also serves as a diagnostic tool for debugging light source or material behaviour.

Platform Updates: macOS Tahoe Joins, Linux Builds Simplified

MoonRay can now build natively on macOS Tahoe, with Sonoma and Sequoia still supported. The renderer also benefits from dependency updates and inculde fixes, easing compilation on a broader range of Linux distributions. The release aligns with both VFX Reference Platform 2024 and 2025, ensuring compatibility with current production libraries and compilers.

New Features Across the Pipeline

Version 2.34.0.1 expands flexibility for lighting and shading setups. Per-lobe lightsets are now available in both vector and XPU modes, allowing finer control of multi-lobe BSDFs. Image maps gain bindable “scale” and “offset” attributes, and SceneVariables documentation for image sizing has been clarified. Performance-wise, MoonRay now shares CPU and memory affinity data between processes using shared memory, improving parallel job efficiency. Timing measurements have switched to a more efficient RDTSC-based method for NUMA [non-uniform memory access] systems, offering more stable profiling results. Artists can also now select lights and cameras for object-space transformations directly in map shaders, simplifying custom shading graph workflows.

Fixes: From Subsurface Scatter to Fisheye Crashes

A long list of bug fixes makes this release notably production-friendly. Key repairs include:

• Fixed a mesh tessellation issue in tiled renders with the FisheyeCamera.
• Resolved DwaTwoSidedMaterial artefacts caused by previous lobe lightset work.
• Corrected crashes when exceeding BSDF lobe limits or loading oversized MeshLights, which now trigger warnings instead.
• Addressed a memory usage spike in vector and XPU modes.
• Fixed missing lightset assignments in vector subsurface scattering and adjusted over-bright subsurface shading on creases.
• Corrected normal direction errors in scalar mode and improved TransformSpaceMap behaviour.
• Fixed adaptive light sampling, volume bounce contributions, and a crash in OpenImageIO 2.4.8 statistics when no images were opened.

Under the Hood: Clean-Up and Refactoring

DreamWorks also restructured several internal libraries. The noise library moved from moonshine/lib/common to moonray/lib/common, simplifying dependencies. The integrator logic for Cryptomatte was reduced in complexity, and redundant intersection path types were removed. Code clean-up continues across lib/rendering/shading, improving maintainability without changing behaviour.

Availability

MoonRay 2.34.0.1 is available now as open-source via the official repository. It can be compiled for Linux and macOS (Tahoe, Sonoma, and Sequoia). GPU rendering requires NVIDIA CUDA/OptiX or Apple Silicon.

Caution Before Production

As with any open-source renderer update, production users should validate the build and test scene compatibility before deployment in live pipelines.

The post Rays Behaving Badly No More: MoonRay 2.34.0.1 Fixes the Path first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pixar has released RenderMan 27.1, a maintenance update that stabilises and refines the hybrid XPU renderer introduced in version 27. The release extends MaterialX Lama functionality, aligns checkpointing with RIS behaviour, and improves stability across DCC integrations.

XPU: coating and checkpointing refined

The hybrid RenderMan XPU renderer now supports coating behaviour in the MaterialX Lama shading system. In practice, base nodes such as LamaDielectric and LamaGeneralizedSchlick correctly adjust absorption when layered with LamaLayer. This brings XPU into parity with the older RIS renderer for complex layered materials.

The update also fixes multiple shading issues. Subsurface scattering in PxrSurface and PxrDisneyBsdf now supports bump mapping when diffuse front-matter parameters are zero. Several Lama-specific bugs have been resolved, including incorrect subset computation inside combiner networks and misweighted LamaSSS importance that led to dim results. Shader memory use has been reduced by roughly 380 MB on GPU, improving efficiency on multi-layered materials.

RenderMan 27.1 also changes how XPU executes checkpoint commands. They are now triggered after a successful render rather than solely after each checkpoint, matching RIS behaviour and improving automation consistency in scripted pipelines.

Lighting and statistics

The release addresses a lighting artefact in the cylinder light’s radiance estimate function and corrects iteration-based pixel reporting in XPU statistics. The live statistics overview for both RIS and XPU now displays active pixel counts alongside iteration numbers. Data in DCC live stats panels now persists correctly after a render stops.

Blender and Houdini integration

In RenderMan for Blender, a bug that prevented AOVs from rendering correctly across multiple sessions has been fixed. RenderMan for Houdini receives several updates: the args2hda tool now generates valid disable and hide conditions, HdPrman automatically sets frame numbers in USD 25.05 and Solaris for older USD versions, and USD plugins have been moved to the dso directory for consistency.

Platform support and licensing

RenderMan 27.1 supports Windows 10+, macOS 15.x+, and glibc 2.34+ Linux. XPU is available on Windows and Linux with NVIDIA Pascal or newer GPUs. Integration plugins are provided for Blender 3.6+, Houdini 20+, Katana 7+, and Maya 2024+. Licences start at USD 845 (perpetual or floating, including 12 months of maintenance), with a non-commercial edition available for free.

Get more iNformation in the Renderman Wiki here.

The post Checkpoint, fixed: Pixar ships RenderMan 27.1 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Pixar’s RenderMan 27.0 is not a mere update: For the first time since the RIS introduction in 2014, RenderMan’s rendering core has been fundamentally rebuilt. The headline act: XPU, Pixar’s hybrid CPU+GPU architecture, now capable of producing final-frame renders. With multi-GPU support, full compositing pipelines, and feature parity with RIS in most production cases, XPU has stepped from experimental preview to the new backbone of RenderMan’s future.

According to Pixar, version 27 marks the most significant performance and interactivity leap in over a decade. The new architecture combines compute scalability with physically based consistency, while also supporting new aesthetic flexibility through a fully integrated Stylized Looks framework.

XPU: From Preview to Production

RenderMan’s XPU engine now operates as a complete production renderer, supporting both CPU and GPU resources simultaneously. This dual utilisation allows artists to push hardware to its maximum throughput, whether on workstations or render farms. The new final-frame rendering mode eliminates the former division between lookdev and production rendering, streamlining pipelines previously dependent on RIS for the last mile. XPU now supports multi-GPU rendering, with the caveat that all GPUs in use must be identical and contain full scene memory. The engine’s minimum requirement has been raised to CUDA 12.8.1, reflecting its deeper reliance on modern GPU driver capabilities. Pixar confirms that this configuration is the foundation for all future RenderMan development.

Adaptive, Smarter, Faster

Under the hood, Pixar’s engineers have reworked adaptive sampling, aligning it with internal techniques used in Pixar Animation Studios’ own productions. Adaptive metrics such as “relativepixelvariance” and “mse” AOV-based control now run per object, delivering more accurate sampling without inflating render times. Checkpointing, a feature long requested by production supervisors, has been fully implemented. Artists can now save partial renders at defined intervals, resuming from checkpoints without rerendering full frames. This system, combined with interactive denoising, significantly tightens iteration loops in look development. The denoiser itself now outputs timing data, integrates directly with live renders, and can be toggled interactively. Pipeline engineers can expect improved configurability for modern, distributed render farms.

Deep Compositing and AOV Control

Version 27 brings complete deep data workflows to XPU. OpenEXR 3.0 Deep IDs are fully supported, allowing compressed ID manifests to be automatically generated for compositing. Artists can extract object-level data directly from deep renders using Pixar’s new deepidextract utility. Compositing teams gain matte and holdout workflows, expanded AOV handling, and support for the shadows and invshadows LPE prefixes. OpenEXR metadata is now written natively, ensuring compatibility with Nuke and other deep compositing tools. Cryptomatte, while not yet part of the initial 27.0 release, is scheduled to arrive in a dot update, according to Pixar’s release notes.

Geometry, Lighting, and Volume Precision

Geometry handling in XPU 27 has been heavily rewritten to achieve parity with RIS. Nested instancing, long a sticking point, now supports material inheritance and attribute propagation without breaking shading hierarchies. Displacement, motion blur, and volume interactions have been stabilised, with notable improvements in the handling of semi-sharp subdivision creases.

Lighting gains precision as well. Mesh lights are now fully supported, and light filters have been corrected for spline and falloff anomalies. The PxrPathTracer integrator adds new clamping controls (clampDepth and clampLuminance), aligning noise handling across both rendering architectures. Volumetric fidelity benefits from the new interior volume aggregates, enabling complex materials such as murky liquids or translucent crystals. Artists can now fine-tune deep shadow error parameters for exact compositing control.

MaterialX Lama: Early Access, Serious Potential

RenderMan 27 introduces MaterialX Lama, Industrial Light & Magic’s modular shading system, as Early Access inside XPU. The system allows layered material construction using physically accurate combiners. Pixar’s current implementation supports LamaDielectric, LamaConductor, and GeneralizedSchlick nodes with anisotropy, single scattering, and extinction behaviour now properly matching or exceeding RIS accuracy. Full support is scheduled during the 27.x release cycle. Pixar notes that look differences compared to RIS are expected in this early phase and requests feedback from studios integrating Lama in production.

Stylised Looks: Non-Photorealism, Physically Based

The Stylized Looks suite has matured from experiment to production toolset. It now ships as a unified subsystem under XPU, comprising PxrStylizedControl, PainterlyBrush, Lines, Hatching, Canvas, and Toon filters. Each operates as a display or sample filter, allowing NPR (non-photorealistic rendering) effects such as painterly brush strokes, toon shading, curvature-based outlines, and cross-hatching, all integrated directly with RenderMan’s physically based lighting.

The system supports AOV outputs, interactive denoising, and compositing passes. The new PainterlyBrushXPU filter enables procedural brush strokes with depth and lighting awareness. StylizedCanvasXPU and StylizedLinesXPU introduce compositing and in-filter distortion options with up to 96 preset line textures. Pixar’s stated goal: to let stylised rendering coexist with physically plausible shading without breaking pipeline compatibility.

Integration and Pipeline Alignment

RenderMan 27 strengthens its integration with major DCC applications and pipeline frameworks. Solaris, SideFX’s USD-based environment in Houdini, now features deeper RenderMan embedding, including improved UI, native support for OpenSubdiv 3.6.1, and GPU progress tracking in hdPrman. RenderMan LOP nodes have been refactored, and “RenderMan Render Vars” replace the older “Standard Render Vars” for more robust USD conformity.

RenderMan for Blender reintroduces Qt-based UIs via PySide6, restoring the texture manager and preset browser on Blender 4.x. Artists now benefit from native light linking, velocity blur control, and on-the-fly texture conversion.

In Maya, RenderMan’s Texture Manager has been modernised, adopting OpenImageIO for mipmapped texture conversion. Pixar’s proprietary texture format has been replaced by OpenEXR, aligning with the VFX Reference Platform 2024 standards. The legacy txmake utility remains available for backward compatibility but is now officially deprecated.

The Texture Manager now supports ACES-compliant defaults, HiDPI UIs, and multi-selection editing. Pixar warns that lowercase <udim> tokens will no longer be recognised; pipelines must adopt the uppercase <UDIM> convention for USD compliance.

Complying with the VFX Reference Platform 2024

RenderMan 27 aligns fully with VFX Reference Platform 2024, standardising on current builds of Python, OpenEXR, OpenImageIO, and USD. For production pipelines, this ensures compatibility with other industry-standard applications and reduces dependency conflicts across render nodes. The change affects texture formats, shader APIs, and compositing metadata. Pixar’s move to OpenEXR for both image outputs and texture caching is particularly significant, replacing proprietary workflows with interoperable standards.

Performance and Statistics

Performance instrumentation across XPU has been expanded, with scene ingestion, GPU allocation, and adaptive ray counters now visible in live statistics panels across DCCs. The stportal interface presents real-time timers, counters, and memory metrics, enabling TDs to diagnose bottlenecks without external profiling tools. RenderMan’s JSON reporting system has been refined for both RIS and XPU, offering standard and detailed modes for automated render diagnostics. Memory tracking now includes deduplication efficiency, critical for large USD scenes.

Future of RIS

While RIS remains functional in version 27, Pixar has confirmed its future deprecation. The renderer continues to support legacy pipelines, but new features including deep compositing, MaterialX Lama, and multi-GPU acceleration, are exclusive to XPU. Pixar recommends transitioning new projects to XPU immediately to ensure feature parity and forward compatibility. The company has maintained RIS only for existing productions requiring deterministic CPU-only rendering or legacy shader behaviour.

Non-Commercial Version – still free.

The free Non-Commercial RenderMan 27 is Pixar’s way of saying, “Go ahead, break it, just don’t charge for it.” The edition now includes full XPU support, right down to final-frame rendering, meaning anyone can experiment with the same hybrid CPU–GPU tech used on Pixar features. It’s designed for personal projects, research, and plugin tinkering, with no watermarks, only a polite request to credit RenderMan if your test project accidentally becomes an internet hit.

Naturally, there’s a catch or two. The licence is strictly non-commercial, locked to two machines, and politely expires every 120 days, because nothing keeps a pipeline sharp like forced renewals. The Stylized Looks suite, Pixar’s NPR playground of painterly brushes and toon shaders, is absent here, reminding users that true artistry still costs a studio licence. Still, for anyone wanting to explore the XPU ecosystem without opening the budget spreadsheet, it’s a generous, production-grade sandbox.

Compatibility, Stability, and What Comes Next

RenderMan 27’s release is a clear signal: Pixar’s renderer is now fully committed to hybrid GPU computing and open pipeline standards. With XPU stabilised for final-frame rendering, Solaris deeply embedded, and MaterialX Lama laying the foundation for unified shading, the software’s architecture is more extensible than at any point in its history. The move to industry formats and the inclusion of non-photorealistic rendering tools reflect Pixar’s recognition that creative flexibility and pipeline efficiency must coexist.

RenderMan 27.0 should be thoroughly tested before deployment in production, especially when adopting early access features such as MaterialX Lama. Pixar’s documentation explicitly requests user feedback to refine those systems during the 27.x cycle.

The post Pixar’s RenderMan 27.0 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

So that’s over and Solaris has grown up together with Karma XPU, the new hybrid renderer. Time to take a look at it!

Although I had experimented with Karma and Solaris (LOPS) time and again, I didn’t want to make the switch until it had fewer teething problems. That was the case with Houdini 20. I also wanted to build up my scenes in Houdini now and then open them up in Omniverse and Marmoset and see if that works. But more on that later…

Karma

There are a few new features in the Karma renderer. The most important one is that the XPU of the graphics card renderer is now out of beta. Many other things – for example dispersion, absorption, nested transparent materials (dielectrics), material blending, geometry lights (not for volumes), rounded corners, hextiling etc. etc. don’t really need to be explained in detail as they are not really innovative – but they are also very useful and complete Karma. An important function in Karma CPU is to be able to set the samples per geo and thus shorten the render times easily and sometimes massively. Unfortunately, it is not yet available in XPU and you have to make do “old skool style” with compositing and tricks.

Solaris (LOPs)

Anyone who has ever worked with a client/art director or director on the lighting of a scene knows what this means for the 3D artist – stress and a lot of organisation. The respective change requests have to be documented somehow, e.g. with screenshots of the parameters or with saved scenes or with copies of lights or their positions. A great deal of discipline is required to ensure that the overview is not lost. But there is now a remedy for this in Solaris. The significantly improved Render Gallery in Solaris is worth its weight in gold, because the status of the scene, e.g. the settings in the LightMixer, is saved with every snapshot and the images in the gallery are saved together with the Houdini scene. They can of course be named and tagged (keywords) and then filtered according to the tags. If a photo agency or the customer works with image numbers, these can be assigned to the snapshots as names and/or tags. A dream come true. This is a real workflow enhancement and normally only part of a pipeline in a larger studio.

Solaris – UI

Solaris is there to provide all the functionalities that are needed when a scene is assembled from geometry, materials, lighting and this should be separated from the geometry creation. It is therefore primarily about a user interface to USD. It is therefore only logical that a lot of improvements have been made to the user interface and a special Solaris LookDev desktop has been added. This then displays the Render Gallery, for example.

Viewport

In addition to the viewport, there are new lighting functions: “Disable Lighting” – switches off the light, e.g. to inspect self-luminous materials. “Headlight Only” – switches off all lights and only displays a direct light. “Dome Light Only” – switches off all lights except for the dome light in the viewport. “Normal Lighting” – displays the current lighting situation The interaction with the light mixer and the very convenient options for positioning lights makes illuminating the scene with Solaris very comfortable.

Render statistics

If you want to render, you want to know why it takes so long or where there is potential for optimisation. The RenderStats, which provide information on memory consumption, render time and much more, help with this. Pretty cool! But unfortunately, some of the information can only be viewed with an HTML viewer, which is cumbersome and annoying. There is also a heat map that shows where a lot of rendering time was used in the image. The metadata is saved in the EXR as JSON and can therefore also be used elsewhere. The UI is still in need of improvement with regard to RenderStats, but as this is the first incarnation of Render Stats, this can be forgiven and we look forward to the next versions.

From SOPS to LOPs

Working in Solaris has generally become much easier and more accessible for freelancers over the years. However, there are also areas where a lot of new things need to be learnt in order to create typical Houdini scenes with many objects or many instances in Solaris. There are two new nodes in H20: The New Merge Point Instancer LOP. In a point instancer prim, each point in a geometry is replaced at view or render time by an instance of the geometry of one of the prims with a “prototype” relationship to the instancer. This LOP allows you to efficiently merge multiple point instances. In this way, only the rest positions of the mesh and the points representing the animated transformations of the parts need to be saved. This means that less space is required on the hard disc. A new geometry clip sequence simplifies and speeds up the saving of valuable clips. With Value Clips, you can split large amounts of data across multiple files. This node should be your first choice when working with value clips.

The USD Scene Graph and Component Builder

For the scene graph to look so nice, the geometry must have attributes that are then used to sort the geo in the graph. The “@Name” attribute is the basic version and the minimum, so to speak. It is better to work with “@path” attributes which, if available, also overwrite “@Name”. So not like in other 3D programmes with drag and drop or something like that. However, it is even better and recommended to use the new “component builder” which takes care of all USD attributes and also the linking with materials. If you do this properly for all assets, you can export the scene as a USD scene and open it in Nvidia Omnisphere, for example.

Rendering

The Clone Control Panel looks almost like the Render Gallery described above. However, it is “only” the first step towards a “Multi-Shot and Multi-Asset Management System”. Nevertheless, it is already impressive and shows where the journey will take us. Anyone who has ever had to create a lighting set-up that looks good from several camera positions at the same time or during a tracking shot will really appreciate this feature, as it allows several render jobs to be running at the same time. The number of cores to be used in each case must be specified beforehand. The network and XPU – i.e. the graphics card – can also be selected. However, this is not limited to different cameras or frame numbers. Different render settings, visibility of objects, lights or whatever else is required can be compared and assessed interactively. This is still a little cumbersome, as the LOPs network has to be built accordingly. BUT so cool and really innovative.

Talking with SideFX

Besides playing with the new tools, DP hopped on a video call with the Karma (and Mantra) developers at SideFX, to get an idea where it is going…

Mark Elendt is a senior mathematician at SideFX. Mark has been with SideFX for over 32 years and worked on a lot of different parts of Houdini. He actually started working on Prisms, which was the product before Houdini. Marks passion is rendering – he wrote the Mantra render engine for prisms and rewrote Mantra for Houdini. And now he is working on Karma, the new flagship renderer from SideFX.

Brian Sharpe is a senior rendering deve­loper at SideFX. He has been in the graphics industry for 25 years, and spent a long time in computer games. He is at SideFX now for six years and working on the Karma XPU renderer.

DP: Karma XPU is marketed as a hybrid renderer. What does that actually mean? What is hybrid about Karma?

Mark Elendt: There are a lot of different purposes for rendering. You‘ve got the film production which has to deal with hundreds of millions of polygons and very complicated shading networks. But you have to provide all the way down to motion graphics, which need a really, really fast turnaround on renderings, or you‘ve got the various different things interior design, architectural design, even scientific visualization. Every renderer has to deal with different types of scenes. We came from Mantra, which was a real workhorse of a renderer – not really fast, but it was very flexible. So we have worked on a new renderer called Karma. Karma actually has two different engines in it. A CPU engine, which deals with very large scenes, but it also has the XPU engine, which can also deal with large scenes and it is geared for faster turnaround and more flexible use of hardware. The more you want to harness the GPU for speed and power, the more restrictive your renderer has to become. Mantra was very flexible. People could write shaders that could reach over to other pieces of geometry and do heaps of wacky stuff. Reach all the nooks and crannies of Houdini and do really powerful stuff.

Brian Sharpe: But then, as you start moving to a more efficient renderer, such as Karma CPU and then Karma XPU which harnesses the GPU so much more, the rendering architecture becomes a lot more rigid and people find they don‘t have so much flexibi­lity, but yet so much more speed. There‘s a trade-off. But we knew we needed to harness the GPU cores and get this really fast performance from them. Karma XPU can harness that, but it‘s a little bit more rigid and a little bit less flexible. But then we have Karma CPU which can still reach into all the nooks and crannies of Houdini to do powerful stuff and access the VEX language, but it‘s CPU only. XPU is a hybrid renderer that just views any sort of CPU or hardware on the machine as potentially executable, So it looks at any kind of GPU and says right, I can use that for rendering. And it also looks at the CPU says right, can I use that for rendering as well. And then it uses both, all the power on the machine to do rendering. It means that you‘re really maximizing performance, but it comes with a lot of benefits as well. For example, if you‘re saying it‘s too big to fit on the GPU memory that you can still keep rendering using only your CPU. So that‘s a very powerful thing.

DP: For me a hybrid renderer would be renderer that is using GPU and CPU at the same time and not using the CPU as a fallback? Maybe sharing the RAM or sharing the memory and doing some clever stuff there – and it would not create different results, even if the GPU is running out of VRAM Is this the case with Karma?

Mark Elendt: Karma’s code is written for the CPU and for the GPU. We find that when you work collaboratively, when you‘ve got both devices working on the same image, the CPU may only do 20 percent of the work, the GPU does 80 percent of the work. In some cases, the CPU only does 10 percent of the work while the GPU does 90percent, but in some cases the CPU does more. Right? It‘s a balance.

DP: And it balances itself and it takes care of that?

Mark Elendt: Yeah. You know, one device will do more work than the other.

DP: Depending on the shaders and what it does?

Brian Sharpe: Certain features like subsurface scattering doesn‘t run as efficiently on the GPUs…

Mark Elendt: If the CPU is only doing 20 percent of the image. And your image takes a minute to render and all of a sudden the GPU can‘t work anymore. Mm hmm. Well, the CPU seems really slow because the GPU was doing 80 percent of the work, so now it‘s only doing 20 percent of the work. The render is going to take five times as long. But we don‘t actually decide what‘s better. We just make every device work at full speed. Both devices can do subsurface scattering. But the GPU is not as efficient during subsurface rendering, so the CPU will take up more of the rendering time. It‘ll contribute maybe 30 or 40 percent of the render instead of only 20 percent. So both devices are working full out to generate the image. But some devices are better at some things.

DP: What about distributed rendering, as in many machines working on one image. Is that something that Karma CPU and XPU can do?

Mark Elendt: XPU is built to have multiple devices. If you‘ve got three GPUs, three graphics cards or four graphics cards in your box and one CPU, you can actually have five XPU devices working collaboratively on the image. It‘s not just one GPU and the CPU, it‘s as many GPUs as you have and CPU, but we can extend that in the future. We can then have other devices that are not necessarily just GPU or CPU devices. Currently it‘s not able to do distributed rendering, but the engine is prepared for it. XPU works by using USD underneath for the scene description. So XPU will take the USD buffers and send the required data to the device. So, if you‘ve got a teapot geometry, it will send that geometry to the GPU and to the CPU device. It might send it over the network to the device and then all the devices have the copies of the data and work together collaboratively to build the final image.

DP: Currently it is a Cuda implemen­tation?

Mark Elendt: Cuda has a lot of the production features that we‘re looking for. High quality programmable shading with C shaders. They‘ve got a very good development toolkit, but that doesn‘t hinder us from developing other devices. Whether we develop a Vulkan device or a metal device, we have the architecture that we can build these new devices using different technologies, and it will all work together on different platforms.

DP: But still also currently not executed?

Brian Sharpe: Currently its CUDA and Optix, whereby Optix is the library toolkit and CUDA is the language you want to plug into.

DP: Why not OpenCL?

Mark Elendt: We‘re leveraging a lot of the technology that comes with Optix and the Nvidida drivers. So it makes it a lot easier for us to have some stepping stones, which make it easier for us to implement.

Brian Sharpe: We can gain access to the RTX hardware. So that‘s the ray tracing hardware on Nvidia GPUs via Cuda OptiX. But they haven‘t exposed that to open CL yet. So if we wrote an openCL device, all the ray tracing would be in software, so it wouldn‘t be as performant. For now on video cards, it looks like we‘ll be sticking with Optix Cuda, but for other GPUs we will see.

Mark Elendt: We are trying to get to the stage where people are already using Karma XPU for production, but we‘d like to get to the stage where everyone feels comfortable and safe using Karma XPU for real production. Once we get there, then we can start expanding into other devices, whether it‘s distributed rendering or Metal or Vulkan or Opencl. So a lot of ways we can go in the future.

DP: What about USD?

Mark Elendt: There is a lot going on in USD development. At SideFX, we started on a look dev project called Solaris. When we started to work on Solaris, we evaluated the possibility of having Mantra ported to import USD and we realized that Mantra was getting a little bit long in the tooth. The architecture was not as flexible as we wanted. At that point we decided it was time for a new renderer and lets call it Karma. That will work straight natively with USD. Karma has got a lot of the rendering heri­tage that mantra has, but it‘s also streamlined and architected for more modern technologies.

Brian Sharpe: The architecture of XPU lives and with the same design principles as Karma CPU, it just chooses to execute the stuff on GPU. But there are things that KARMA XPU can‘t do, such as running things like VEX, so I decided just to leave it on the shelf for now and just concentrate on getting the MaterialX version going.

Mark Elendt: A lot of the technologies that KARMA is building on are open source and part of the Academy Software Foundation, the ACLU group. USD is not part of ASF yet, though they do have a working group. But again, it‘s a relatively new project. It‘s been used in ILM for four years and getting larger exposure recently. Autodesk is doing a lot of work on MaterialX, AMD has a big MaterialX gallery that you can download directly in Houdini20 and USD has a built in MaterialX support. So all of these software libraries work well together. Leveraging that means that users will be more familiar with the concepts. Well, what we‘re finding is MaterialX has a lot of the features that we need and is very general and flexible, but there are certain things that it doesn‘t have support for yet. We‘re working with the MaterialX team, we‘re pushing nodes up to them and working with them on building and extending and making MaterialX more flexible and more accessible to everybody.

Brian Sharpe: It‘s I‘ll add one thing to that, what we‘re finding and one really good reason and one really good benefit that we‘ve got Karma XPU. And also our CPU engine under the one umbrella, which is Karma is if someone‘s working within KARMA XPU and they‘re doing all their work and their are using MaterialX, they really do find this a certain feature that they just cannot exist, such as casting an arbitrary ray from a shader or something there is always a fallback to our Karma CPU render and do all that stuff in VEX that we really have to do. So that could be in the middle of production and they‘re not going to at that moment look out for another renderer. They keep going because there‘s a big safety net in Karma CPU.

Mark Elendt: And that‘s always been a philosophy of SideFX. Which is not to make users hit any brick walls. You want to be flexible enough that you can do anything, with Karma. We‘ve sort of pulled the reins in a bit, but we still have those back doors that if you are really savvy where you really are stuck, you can get out of the problem and solve your solution.

DP: Any plans for a sort of real time incarnation of Karma?

Mark Elendt: No. Karma is always going to be a path tracing renderer. There are path tracers out there that are real time, but they are specifically written for real time. So, they will send very few rays and rely on denoise. Karma is really intended to be a more general-purpose offline renderer. You get really fast feedback and sometimes images can take just seconds to render, but that‘s not real time. It‘s interactive.I think you might be able to look for something coming in the Houdini viewport that the real time rendering in the viewport using OpenGL or Vulkan the Raytracing support. The two types of rendering are getting closer together. We might end up with raytraced reflections in the viewport or some raytraced, soft shadows or something like that. But you may not get the subsurface scattering and the high-fidelity kind of lighting that you would get with Karma.

DP: What about denoising?

Mark Elendt: I don‘t think that we‘re going to spend a lot of research time on denoise theories at SideFX, but there are a lot of public denoisers and even proprietary denoisers which we can leverage inside of the architecture. We have integrated the OptiX denoiser and as well as the Intel Open Denoiser into Karma and we are also working with Nvidia. We feed back data to them and discuss denoising issues, but we let them do the lion‘s share of the heavy lifting.

Brian Sharpe: What we have in Karma CPU already is the automatic convergence mode, where Karma is smart about where it sends the rays. Where an area of noise is Karma hammers it with more samples.

DP: Is there anything that you think you want to tell the readers about the future of XPU?

Brian Sharpe: One thing needs a bit more explanation, the CPU running out of m­emory. And in extreme cases it can. But we‘re currently working on out-of-core rendering for you, so it doesn’t mean it‘s going to magically work on a one gigabyte scene or something, but it‘s going to get a lot better with memory going forward!

The post USD, Solaris and Karma in Houdini 20 (and elsewhere…) first appeared on DIGITAL PRODUCTION and was written by Olaf Finkbeiner.