Karma XPU Render Farm in 2026: RTX 5090 Driver Rules and the OptiX Error

Karma XPU runs on the RTX 5090 without needing a special Blackwell build, which sets it apart from renderers that had to ship new versions before the card appeared at all. What catches people out instead is the driver and a shader compilation error. On some RTX 5090 setups Karma XPU fails with a message about not being able to create the OptiX pipeline, and the workaround shared on the SideFX forum is to set KARMA_XPU_OPTIX_FORCE_OPTIXIR to 1 in houdini.env. Beyond that, check the NVIDIA driver branch against the system requirements for your Houdini build, because specific branches are recommended and at least one is called out to avoid. Karma XPU also supports only CPU and NVIDIA OptiX devices, and memory is never pooled between them.

Does Karma XPU need a special build for the RTX 5090?

Image Source: Side FX

No. Karma XPU renders on Blackwell cards without a Houdini release built specifically for that architecture, which is the opposite of the situation with several other GPU renderers. 

That does not mean the card drops in and works. The two real barriers are the driver branch and a shader compilation error, and both of them produce symptoms that look nothing like a compatibility problem. Karma XPU documentation states that XPU currently supports only CPU and NVIDIA GPU hardware, split into the OptiX GPU engine and the Embree CPU engine. AMD and Intel cards are not an option for the GPU half.

Why does Karma XPU fail with a Failed to create Optix pipeline error?

This is a failure at the shader compilation stage, and on RTX 5090 setups the workaround circulating on the official SideFX forum is to force XPU to use the OptiX IR compilation path through an environment variable.

The symptom is specific enough to recognise. Rendering stops, and the console reports that the OptiX device carrying the RTX 5090 has registered a critical error about failing to create the OptiX pipeline due to a shader compilation fault, followed by a note that the device will stop functioning and further errors will be suppressed. 

The fix reported in that forum thread is a single line added to houdini.env: KARMA_XPU_OPTIX_FORCE_OPTIXIR = 1

For anyone who has not edited that file before, it lives in your Houdini user preferences folder, not in the install directory. 

Which NVIDIA driver should I use for Karma XPU on an RTX 5090?

Use the branch named in the system requirements page for the Houdini build you are running. SideFX publishes a minimum, a recommended branch, and branches to avoid, and the list differs by operating system.

Driver version carries more weight for XPU than it does for ordinary viewport work, because the GPU half of XPU runs on OptiX, and OptiX ships inside the NVIDIA driver rather than alongside Houdini. When the branch is wrong, you do not get a polite compatibility warning. You get a device that refuses to initialise, or one that compiles shaders incorrectly.

Houdini 22 system requirements state the following for NVIDIA RTX and GeForce cards. On Windows, driver 580.0 Production or Studio is the baseline with 595 recommended, and 590 should be avoided. On Linux, 580.0 Production or Studio is recommended, and both 590 and 595 should be avoided. 

How much VRAM does Karma XPU need, and does a second card add memory?

The Houdini 22 system requirements ask for 12GB of VRAM or more on the graphics card. That is a floor for running the software, not a comfort level for a heavy scene, and the 32GB carried by the RTX 5090 is the best option.

Adding a second card does not raise that ceiling. The Karma XPU documentation states that each GPU device is addressed separately and memory is not pooled, so two 32GB cards are two separate 32GB pools rather than one 64GB pool. This is the point people get wrong when they buy a second card to solve a memory problem. If your scene overflows one card, a second card renders the same overflow twice. If your scene fits but renders slowly, a second card genuinely helps, because XPU will use every compatible device it detects.

What happens when a GPU runs out of memory mid render?

The frame still completes. The Karma XPU documentation states that if a device fails, as may happen with a GPU running out of memory, the other devices including the CPU pick up the load and finish the frame, and that no matter what mixture of devices it uses, XPU should produce the exact same result.

Your image comes out correct, so nothing prompts you to investigate, and the only evidence is a render time that is worse than it should be. On a workstation that costs you an evening. On a farm node billed by the hour, you are paying GPU prices for a CPU only render.

Which render farms support Karma XPU?

Karma XPU support is narrower than support for the mainstream GPU renderers, so the first question is not price. It is whether the farm runs Houdini with the XPU engine at all, and at which version.

Karma XPU is comparatively new and tied to Houdini alone, so the number of services that support it well is smaller than the number that support Blender or Redshift. On a job submission service you cannot set either, because the machine image belongs to the operator. On a whole machine rental you install the Houdini build, the driver and the houdini.env entries yourself. For a studio rendering a masterplan sequence where every frame has to match, that control is the whole argument.

Fox Renderfarm: A SaaS service where scenes are submitted through an automated manager. Check the supported software list for Houdini and confirm whether the XPU engine specifically is covered, since Houdini support and Karma XPU support are not the same statement.

GarageFarm: A SaaS service known for responsive human support when a job fails on configuration rather than on the scene, which is useful given how XPU failures present. 

iRender: An IaaS service where you rent the whole node by the hour and build the environment yourself, which means installing your exact Houdini build, choosing the driver branch, and adding your own houdini.env entries including the OptiX IR workaround if your setup needs it. RTX 4090 24GB servers start from around $8.20 per hour, and the single card RTX 5090 32GB node is listed at $10.8 per node hour, falling to $9.72 from three hours. The drawbacks: billing runs until you shut the node down manually, the first setup session costs time before it renders anything, and you rent CPU and GPU together with no way to choose your own balance between them.

RANCH Computing: A SaaS service with automated pre flight checks on scene integrity and asset paths. 

RebusFarm: A SaaS service structured around a submitter plugin installed into the host application. Check the supported software list for Houdini and for the XPU engine, and check the GPU listings on their portal.

SuperRenderFarm: A SaaS service to evaluate on the same points: whether Houdini with Karma XPU is supported, at which versions, and what hardware sits behind it. 

Farm	Model	What to check for Karma XPU	Note at time of writing
Fox Renderfarm	SaaS	Houdini and Karma XPU support, and at which versions	Check the software list and GPU configuration on the official page
GarageFarm	SaaS	Houdini support, and whether any config can be applied per job	Strong human support on configuration errors, re-check XPU scope
iRender	IaaS	You install the Houdini build, driver and houdini.env yourself	RTX 4090 24GB and RTX 5090 32GB nodes; billing runs until you shut the node down; first setup takes time
RANCH Computing	SaaS	Whether Houdini and Karma XPU are supported	Publishes card tiers including RTX 5090, confirm the software scope
RebusFarm	SaaS	Houdini and Karma XPU support in the submitter	Check the software list on the official page
SuperRenderFarm	SaaS	Whether Houdini and Karma XPU are supported	Check the software list on the official page

None of this makes SaaS the weaker choice. If a farm has already validated Karma XPU on its fleet, it has done it on hardware you never have to configure, with no machine to forget about at the end of the night. That is a real saving, and for a straightforward sequence it is the lower risk path.

IaaS earns its place when the environment is the problem, which for Karma XPU it frequently is. Renting the machine gives you the driver branch you want, the Houdini patch build you tested against, and the environment variables your setup needs.

What should I check before sending a Karma XPU job to a farm?

Match the Houdini build between your machine and the farm, down to the patch version where you can. Confirm the driver branch on the render nodes against the system requirements for that build. If you are relying on the OptiX IR workaround locally, make sure the same environment variable exists on the farm side, because without it the job fails there in exactly the way you just finished fixing at home. Then render one test frame, read the log, and confirm which devices actually participated before you send the whole sequence.

FAQ

1. Does Karma XPU support the RTX 5090?

Yes, and it does not require a Houdini build made specifically for the Blackwell architecture, unlike several other GPU renderers that had to ship new versions before the card was usable at all. 

2. How do I fix Failed to create Optix pipeline in Karma XPU?

The workaround shared on the official SideFX forum is to add KARMA_XPU_OPTIX_FORCE_OPTIXIR = 1 to your houdini.env file and restart Houdini. That file sits in your Houdini user preferences folder, named for your version, not in the installation directory. 

3. How much VRAM does Karma XPU need?

The Houdini 22 system requirements ask for 12GB of VRAM or more on the graphics card, and the Karma XPU documentation separately asks for a GPU with Compute Capability 5.0 or higher. 

4. Do two GPUs give Karma XPU more memory?

No. The Karma XPU documentation states that each GPU device is addressed separately and memory is not pooled, so two 32GB cards remain two separate 32GB pools rather than a shared 64GB pool. 

5. What happens if the GPU fails during a Karma XPU render?

The frame still completes. The documentation states that when a device fails, for example a GPU running out of memory, the other devices including the CPU pick up the load and finish the frame, and XPU produces the same result regardless of which mixture of devices was used. The downside is that you may not notice the GPU dropped out, and will only see an unusually slow render. 

See more: How to Stop CUDA/OptiX Out-of-Memory Crashes in Blender Cycles

Part of our guide: for a full overview of cloud options, see the Houdini render farm guide.