On this page

Overview

Karma XPU is a selectable engine of the Karma renderer that makes use of both CPU and GPU resources simultaneously. It will use any compatible devices it can detect, including multiple GPUs. If a device fails, as may be the case with a GPU running out of memory, the other devices (including the CPU) will pick up the load and finish rendering the frame. No matter what mixture of devices it uses, the XPU engine should produce the exact same result.

Karma XPU is split into the Optix GPU and Embree CPU engines. In systems with multiple graphic cards, you will also see an appropriate number of Optix devices in the viewport. Note that each GPU device is addressed separately and memory is not pooled.

Tip

If you only want to use the Optix GPU engine you can turn off the Embree CPU engine through an environment variable: KARMA_XPU_DISABLE_EMBREE_DEVICE=1. See disabling devices for more details.

An important concept with Karma is sampling, because it has strong impact on render times and the quality of the rendered image. You can read more about sampling and how it works in Karma XPU in the Karma User Guide.

Because Karma XPU uses GPU hardware acceleration, it is very fast compared to the CPU-only engine. However, XPU may have less functionality, and/or generate different output from the CPU-only engine. Karma XPU is not a replacement for the Karma CPU engine, but rather a high-performance alternative with limited feature set.

Supported Hardware

  • Karma XPU currently only supports CPU and NVidia GPU hardware (support for other GPU hardware will come in the future).

  • NVidia users will require a minimum driver version of 535 (545+ recommended for Linux, 546.33+ strongly recommend for Windows), and a GPU of Compute Capability 5.0 (Maxwell) or higher.

  • Machines without an NVidia GPU (e.g. Apple Silicon) will only make use of the Embree CPU device.

Shading Overview

The Karma Material Builder is recommended as the way to build materials for Karma XPU. This will provide access to all of the compatible Karma and MaterialX nodes. If you need a strictly MaterialX-only set of shaders, use the USD MaterialX Builder. See the Materials chapter in the Karma User Guide for more details.

Note

Only USD Preview Surface, MaterialX and Karma-specific VOP nodes such as the Karma Hair Shader are supported by XPU. Everything else, e.g. the Principled Shader will either not work, or be an approximation at best.

On startup, Karma XPU must compile shaders into device-specific formats. This process will cause the XPU to pause/stutter when you load a new scene or enable a new feature. The compiled results are cached, so rendering the same scene will not pause for shader compilation after the first time.

When first using XPU, or with new installations of Houdini, or on a new GPU driver, the initial compilation steps can take up to 1-2 minutes. But because of the caching, further compilation stages should be a lot faster. Below you can see a video of the compilation process and the increase of render speed when the Optix engine kicks in.

How To

To...Do this

Use Karma XPU to render the Solaris viewer

  1. Click the Viewport Options menu in the viewport and choose Karma XPU.

  2. Click Display Options in the display toolbar (to the right of the viewer) or press D in the viewer.

  3. In the display options window, click Render tab, and set the Rendering Engine to XPU Engine.

    These render settings are saved with the current .hip file.

  4. Close the Display Options window.

Display device and render stats in the viewport

  1. Click Display Options in the display toolbar (to the right of the viewer) or press D in the viewer.

  2. In the display options window, click Guides tab, then enable Render Stats.

  3. Close the Display Options window.

Do a full render using Karma XPU

On the Karma LOP, set the Render Engine parameter to XPU Engine.

Viewport

In the viewport you’ll see the active devices in the top right of the screen under the render progress readout. The devices will be listed as either “Optix” or “EmbreeCPU” with a status text in the square brackets. Status can be one of the following:

  • “idle” - the device is not doing any work

  • “init” - the device is initializing

  • “compile” - the device is compiling shaders

  • “fail” - the device has failed

  • a percentage number representing how much that particular device has contributed to the current image so far (its expected GPU devices like “Optix” will contribute far more than “EmbreeCPU” given Karma XPU has been written and optimized for GPU).

It is also possible to see more detailed information about the individual devices in the render stats.

Supported features and limitations

  • Karma XPU supports the following render settings:

    • Override Lighting

    • Disable Lighting

    • Enable Denoising

    • Enable Depth of Field

    • Path Traced Samples

    • IPR Bucket Size (controls resolution of the preview frame)

    • IPR Reserve Threads (XPU is more responsive if you set this to 2 or 3)

    • Light Sampling Mode

    • Light Sampling Quality

    • Dicing Quality Scale

    • Disable Motion Blur

    • Enable Depth of Field

    • Automatic Headlight Creation

    • Ray Bias

    • Automatic Ray Bias

    • Russian Roulette Cutoff Depth

    • Constrain by Maximum Roughness

    • Color Limit

    • Shared Color Limit

    • Indirect Color Limit

    • Pixel Filter Size (only gauss pixel filter supported ATM)

    • Random Seed

  • Supports the following render geometry settings:

    • Render Visibility

    • Geometry Time Samples

    • Transform Time Samples

    • Enable Caustics

    • Evaluate BSDF on Fake Caustics

    • Fake Caustics Color

    • Fake Caustics Opacity

    • Enable Internal Reflection

    • Caustics Roughness Clamp

    • Diffuse Limit (range 0 to 255)

    • Reflection Limit (range 0 to 255)

    • Refraction Limit (range 0 to 255)

    • Volume Limit (range 0 to 65535)

    • SSS Limit (range 0 to 255)

    • Fix Shadow Terminator

    • Holdout Mode

    • Direct Refraction Subset

    • LPE Tag

    • True Displacements (only supports MtlX Standard Surface)

    • Dielectric Priority

    • Cull Backface (only supports Polymesh)

    • Uniform Volume (see Uniform Volume section below)

    • Volume Step Rate

    • Treat As Light Source (used for geometry lights, see Lighting section below)

    • Light Source Diffuse Multiplier (used for geometry lights, see Lighting section below)

    • Light Source Specular Multiplier (used for geometry lights, see Lighting section below)

    • Light Source Sampling Quality (used for geometry lights, see Lighting section below)

    • Is Portal (see Lighting section below)

    • Portal Dome Lights (see Lighting section below)

  • Supports selection, highlight, and USD purposes when used as an interactive viewer.

  • Supports motion blur (and all its associated settings), including light blur, camera blur, transformation blur, deformation blur and volume motionblur.

  • Supports all camera settings (including Physical Lens Shader).

  • Supports USD Mesh/Polygon prims, details:

    • Supports all primvars except for string-typed primvars

  • Supports USD BasisCurves prims, details:

    • Supports only linear, cubic-bspline, catmull-rom and 'cubic-bezier' types

    • Supports only rounded-tubes rendering

    • Does not support disabling backface culling

    • Supports all primvars except for string-typed primvars

    • Memory consumption on Optix devices can be reduced (with some performance loss) via the KARMA_XPU_OPTIX_CURVE_OPT_LEVEL environment variable (1 = low-mem, 2 = mid-mem (default), 3 = high-mem).

    • S coord is supported (to achieve a cylindrical mapping), but requires 'N' attribute (equivalent to ribbon normal) to serve as guiding orientation.

  • Supports points, details:

    • Does not support backface culling

    • Supports all primvars except for string-typed primvars

    • Does not support disk or orientated-disk types

  • Supports volumes, details:

  • Supports uniform volumes, details:

    • Enable via “Uniform Volume” render geometry setting

    • Only supported on USD Mesh/Polygon prims

    • Only Karma Volume VOP working

  • Supports nested instancing, including per-instanced properties

  • Supports Cryptomatte.

  • Supports Deep Output

  • Supports Named coordinate systems provided by UsdShadeCoordSysAPI

    • Supported in the MtlxPosition, MtlxNormal, MtlxTangent and MtlxBitangent nodes

    • Not yet supported in the MtlxTransformPoint, MtlxTransformNormal and MtlxTransformVector nodes

Materials/shading

Note

We strongly recommend using the Karma Material Builder tool and its associated shaders. Other shader types, i.e. the Principled Surface are not or only partially supported. These shaders might work, but often create unexpected results in many situations, because they're converted into a USDPreviewSurface with a limited feature set.

Please also see the chapter about textures below.

Summary

Details

  • General notes:

    • “index” parameter to Mtlx Tangent, Mtlx BiTangent and Mtlx GeomColor nodes currently ignored

    • The base/index0 UV stream can be named any one of these: “uv”, “st” (selection is made in that order)

  • Unimplemented MaterialX standard library nodes:

  • USDPreviewSurface:

    • “occlusion” parameter ignored

  • mtlxStandardSurface:

    • “transmission_scatter”, “transmission_scatter_anisotropy” and “transmission_extra_roughness” are ignored

    • Unlike the MaterialX standard, “thin_walled” will work as expected

    • SSS only supported on Mesh/Polygon prims

  • blending of two mtlxStandardSurface nodes via mtlxmix:

    • Does not support the mixing of SSS or transmission-depth/absoption properties.

  • Karma Fog Box

    • “Volume Samples” parameter ignored

Textures

  • Textures used by shaders are loaded from disk on-demand in tiles (eg 128×128). They are also loaded into GPU memory on a per-tile basis. If XPU detects the GPU memory as being full mid-render, it will evict non-essential memory and continue rendering. This process will repeat until the render is complete. The GPU will slow down significantly when in this “eviction” state. GPU memory usage can be monitored via the on-screen render stats render stats, as well as showing when eviction has been detected.

    • GPU tiled/sparse textures can be disabled via the KARMA_XPU_OPTIX_SPARSE_TEXTURES environment variable

    • Geometry primvar data is also loaded on-demand.

    • Textures used by lighting are not loaded on a per-tile basis, and also do not go through this eviction/out-of-core system.

  • If a texture does not contain mipmaps, an auto-mipmapping process is applied, with the results cached as a new fully-mipmapped file that sits beside the original in RAT format. See docs for environment variable HOUDINI_TEXTURE_DISK_CACHE for more details.

  • Mipmapping can be disabled via the KARMA_XPU_DISABLE_MIPMAPS environment variable.

  • The resolution of textures used by shaders can be limited via the environment variable KARMA_XPU_MAX_SHADER_TEXTURE_RES. A value of 0 is the default, which means unlimited. Any value above 0 will apply a limit (eg 128 would limit the maximum texture resolution to 128×128).

  • The resolution of textures used by lighting can be limited via the environment variable KARMA_XPU_MAX_LIGHTING_TEXTURE_RES, which has a value of 8192 by default.

  • UDIMS are limited to a range of 10×10 (configurable via the environment variables KARMA_XPU_MAX_UDIM_U and KARMA_XPU_MAX_UDIM_V).

  • Optix devices use the GPU hardware to perform linear filtering. Sometimes this can produce artifacts (especially with normal mapping). With normal mapping the recommended fix is to use cubic-filtering, which can be set using the MtlxImage node. Otherwise XPU can be forced to do its own high-quality linear filtering (via the KARMA_XPU_OPTIX_HQ_LINEAR_FILTERING environment variable) with some performance loss.

Lighting

  • Supported types (Point, Rectangle, Sphere, Disk, Cylinder, Distant, Dome, Karma Physical Sky).

  • Supports Point and Rectangle Geometry Lights, Does not support Volume or Curves Geometry Lights

  • Shaping features are supported (ie spotlights, barndoors, focus, IES profiles)

  • Supports LightLinking

  • Does not support ShadowLinking

  • Supports Portal Lights (portal geometry should not have overlapping polygons)

  • Supports Light Filters (kma_lfilter_gel, kma_lfilter_gobo, kma_lfilter_barndoor, kma_lfilter_attenuation)

  • Supports the following light properties:

    • Everything in the “base properties” tab

    • Enable + Color (shadow tab)

    • Distance (shadow tab)

    • Contibutes Caustics (karma tab)

    • Sampling Quality (karma tab)

    • Sampling Mode (karma tab)

    • Maximum HDRI Size (karma tab)

    • Contibutions (karma tab)

    • Single Sided (karma tab)

    • Point Light Radius (karma tab)

    • Render Light Geometry (karma tab)

    • Light Geometry Casts Shadow (karma tab)

    • Spread (karma tab)

    • LPE Tag (karma tab)

    • Textures working on both dome and rectangle lights (environment variable KARMA_XPU_MAX_LIGHTING_TEXTURE_RES sets the maximum resolution, default=8192)

    • Currently only supports lat-long environment map textures on domelights (that is, does not support sixpack or cubemap environment maps).

AOVs

  • LPEs are supported (including shadow and holdout)

  • There is some limited support for Background plate

  • Shaders can export AOVs using a Karma AOV node. More details here.

  • Supports custom user primvars, except for string-typed primvars.

  • Supports the following Pixel Filters on AOVs:

    • accumulate (Adds Up Sample Values)

    • ubox (Average Sample Values)

    • minmax:min (Minimum value)

    • minmax:max (Maximum Value)

    • minmax:ocover (Object With Most Pixel Coverage)

    • minmax:edge (Disable Edge Anti Aliasing)

    • minmax:idcover (Object With Most Coverage(no filtering)

  • Supports the following hardcoded AOVs:

    • Cf

    • Af

    • vex:export_basecolor (ie “albedo”)

  • Supports the following hardcoded ray AOVs, always in world space:

    • ray:D

    • ray:time

    • ray:near

    • ray:far

    • `ray:contrib'

    • ray:hit

    • ray:hitP

    • ray:hitPz

    • ray:element

    • ray:primid

    • ray:hituv

    • ray:hitdist

    • ray:hitN

    • ray:hitNg

    • ray:objectid

    • ray:backface

    • ray:pixelsamples

    • ray:hdprim

    • ray:hdinst

  • Supports the following hardcoded stat AOVs

    • stat:indirectraycount

    • stat:cputime

  • Supports the following hardcoded primvar AOVs, always in local space:

    • primvar:P

    • primvar:N

    • primvar:Ng

    • primvar:T

    • primvar:B

    • primvar:width

    • primvar:displayColor

    • primvar:uv

    • primvar:st

Disabling devices

Set one or more of the following environment variables in your environment, json package, or houdini.env.

Variable

Effect

KARMA_XPU_DISABLE_OPTIX_DEVICE

If this env var is set, Karma XPU will not use any Optix GPU devices.

KARMA_XPU_DISABLE_EMBREE_DEVICE

If this env var is set, Karma XPU will not use any Embree CPU devices.

KARMA_XPU_DISABLE_DEVICE_n

If this env var is set, Karma XPU will not use device number n. For example, to disable device 3 in a multi-GPU setup:

export KARMA_XPU_DISABLE_DEVICE_3 = 1

Solaris

USD

Geometry

  • SOP Geometry I/O

    Details of how Houdini converts SOP geometry to USD, and how you can control the process.

  • Component Builder

    The Component Builder tool puts down a network snippet for creating a USD model from SOPs, with support for materials, variants, payloads, and layering.

Layout

  • Edit node

    Interactively transforms prims in the viewer. Can use physics collisions to position props realistically.

  • Layout node

    Provides tools for populating a scene with instanced USD assets. You can place individual components, paint/scatter components in different ways using customizable brushes, and edit existing instances.

  • Custom Layout Brushes

    How to create layout brush digital assets you can use to customize the behavior of the Layout LOP.

Look Development

  • MaterialX

    Houdini has VOP node equivalents of the MaterialX shader nodes. You can build a shader network using these nodes, or import an existing MaterialX-based shader, and use them with Karma (Houdini’s USD renderer).

  • UDIM Paths

    You can encode different tiles of a texture space into different texture files, each with its own resolution. You can then specify a texture filename such as kaiju.exr, and Houdini will replace the token with the specific tile address at load time.

  • Shader Translation Framework

    Describes the Solaris shading framework, including shader node translation to USD primitives.

Karma rendering

Tutorials