Houdini 19.5 Solaris

Karma XPU beta

On this page

Overview

The XPU engine is currently in beta. It is still under development. The current functionality is unfinished and subject to change, and may have thin or no documentation. Please bear this in mind when using it. Also please note that this help page represents XPU as of the latest daily release.

Karma XPU is a selectable engine of the Karma renderer that uses CPU resources and also takes advantage of the GPU and hardware acceleration. 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.

Because it uses hardware acceleration, Karma XPU is extremely fast compared to the CPU-only engine. However, XPU may have less functionality, and/or generate less-correct or just different output from the CPU-only engine.

Karma XPU is not (currently) a replacement for the CPU engine, but rather a high performance, feature-limited subset intended to accelerate iterations for artists. XPU is useful for generating fast, high-quality preview renders, within its current capabilities.

Supported Hardware

  • Karma XPU currently only supports CPU and NVidia Optix devices, with Optix being the most optimized code path in XPU. Future versions are expected to have improved CPU performance and support more GPU hardware.

  • NVidia users will require a minimum driver version of 495.89, and a GPU of Compute Capability 5.0 (Maxwell) or higher

Shading Overview

Karma XPU supports the built-in USD materials (such as the USD Preview Surface), and MaterialX, which is probably the future of shading in Karma.

Any VOP shaders with Karma in the name (such as the Karma Hair Shader) should be the same between CPU and XPU (there may be subtle differences in shading due to differences with BSDF evaluation or curve intersection, but they are executing the same code).

Note

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.

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.

  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

  • “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

    • 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

    • Caustics Roughness Clamp

    • Diffuse Limit

    • Reflection Limit

    • Refraction Limit

    • Volume Limit

    • SSS Limit

    • Fix Shadow Terminator

    • “Matte” holdout mode

    • LPE Tag

  • 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 except Lens Shader.

  • Supports USD Mesh/Polygon prims, except:

    • Does not support backface culling

    • Supports all primvars except for string-typed primvars

    • Does not support per-instance settings yet

  • Supports USD BasisCurves prims, except:

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

    • Supports only rounded-tubes rendering

    • Does not support turning off backface culling

    • Supports all primvars except for string-typed primvars

    • Does not support per-instance settings yet

    • Memory consumption on Optix devices can be reduced (with some performance loss) via the KARMA_XPU_OPTIX_CURVE_OPT_LEVEL environment variable.

  • Supports points, except:

    • Supports all primvars except for string-typed primvars

    • Does not support per-instance settings yet

    • Does not support disk or orientated-disk types

  • Supports volumes, except:

Materials/shading

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 Nodes:

  • UsdPreviewSurface:

    • “occlusion” parameter ignored

  • mtlxStandardSurface:

    • “coat_normal” parameter ignored

    • “specular_rotation” and “coat_rotation” combine together to perform a single rotation of the tangent (rather than rotating independently as per the spec)

    • As per MaterialX, the only transmission parameters that work are “transmission” and “transmission_color”, all others are ignored

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

  • Karma Fog Box

    • “Volume Samples” parameter ignored

Textures

  • Currently, textures are loaded into GPU memory on-demand (in ~64×64 tiles) while rendering and will mostly remain on the GPU. XPU only has limited ability to flush the GPU cache, meaning the GPU can still run out of memory. Because of this, XPU has some fixed limits for textures (see below). GPU memory usage can be monitored via the on-screen render stats render stats. Cases where XPU will flush the GPU texture cache are…

    • whenever a texture is created or deleted (in IPR)

    • each frame for offline rendering

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

  • Texture resolution is limited to 2048×2048 (configurable via the environment variable KARMA_XPU_MAX_TEXTURE_RES).

  • 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).

  • Does not support Geometry lights.

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

  • Supports LightLinking

  • Does not support ShadowLinking

  • Supports LightFilters (kma_lfilter_gel, kma_lfilter_gobo, kma_lfilter_barndoor)

  • Supports the following light properties:

    • Everything in the “base properties” tab

    • Enable + Color (shadow tab)

    • Sampling Quality (karma tab)

    • Force Uniform Sampling (karma tab)

    • Maximum HDRI Size (karma tab)

    • Single Sided (karma tab)

    • Render Light Geometry (karma tab)

    • Light Geometry Casts Shadow (karma tab)

    • LPE Tag

    • Textures working on both dome and rectangle lights.

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

AOVs

  • LPEs are supported

  • Shaders can export AOVs using a kma_aov node with the name set to aov:name.

    For example, create a kma_aov node in your MaterialX shader netwrok with the name set to aov:foobar, then add foobar as the name of a Render Var in the render node, with the Source Type set to Raw.

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

  • Supports the following hardcoded AOVs:

    • Cf

    • Af

    • lpe:C.*

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

    • ray:D

    • ray:time

    • ray:hit

    • ray:hitP

    • ray:hitPz

    • ray:element

    • ray:primid

    • ray:hituv

    • ray:hitdist

    • ray:hitN

    • ray:hitNg

    • ray:objectid

    • ray:backface

    • ray:hdprim

    • ray:hdinst

  • 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

  • Importing SOP geometry into USD

    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.

Shading

  • Shader Framework

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

  • Using MaterialX in Solaris

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

  • UDIM

    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.

Karma rendering

Tutorials