Research implementation · GPU testing pending

GPU rendering, one checked frame at a time.

Render images from a defined scene for product visualisation or a frame-based creative workflow. Our first rendering kit builds an original fixed scene, renders a bounded set of PNG frames and compares them with separately rendered CPU output.

Create an account and describe your workload →

What this batch could help with

Product visualisation research

Evaluate lighting, materials and output quality on a small original scene. Commercial product assets need explicit permissions and a separately approved ingestion process.

Frame-based delivery

Compare how a sequence behaves when each frame has a defined scene version, seed and render settings. Keep the frame order and output hashes with the result.

Renderer compatibility

Check whether the installed Blender build can actually use the selected CUDA or OptiX backend. A GPU model name alone does not establish Cycles compatibility.

How the research workload runs

  1. Start with a fixed scene

    The kit creates an original cube, plane, camera and area light. It does not open customer .blend files, external assets or executable scripts.

  2. Select an installed GPU backend

    Start Blender in factory/background mode and explicitly request CUDA or OptiX. Disable CPU render devices for the GPU run and stop when the requested backend is absent.

  3. Render and compare

    Save PNG frames and per-frame evidence. Independently render the same scene on CPU with the same Blender version and settings, compare the images and visually review the result.

Inputs and limits

The first runner produces 1–16 frames with 64–512 pixels per side and 16–256 samples. It uses a fixed random seed, no adaptive sampling and no denoising. General customer scenes, animation imports and render-farm dispatch are not enabled.

Software requirements

An already installed Blender build with a working Cycles GPU backend. CUDA and OptiX availability varies by software build, hardware and platform; this kit does not establish support for every GPU or for the DGX Spark environment.

Results and checks

The JSON report records Blender version, selected compute backend and detected device names, original scene version, resolution, sample count, frame hashes and render times. Non-finite, empty or incorrectly sized rendered images fail validation.

The comparison checks matching scene/settings and verified output files. For the fixed research scene, normalised RGB maximum error must be at most 0.2 and each image mean error at most 0.02. These provisional tolerances require visual review and are not production acceptance criteria.

When a GPU is useful

Render time depends on scene complexity, lighting, samples, renderer version and supported GPU kernels. Do not extrapolate a simple cube benchmark to a complex production scene. CPU and GPU images can differ slightly, so the first comparison uses explicit pixel tolerances plus visual review.

Useful future quote units are accepted frames with a scene version, resolution, renderer and sample policy. Include asset transfer, startup, rerenders, verification and storage when calculating the delivered cost.

No published performance or price is established for this new workload. The embeddings benchmark does not predict its speed or accuracy.

Try the controlled research kit

The implementation runs locally in an existing reviewed environment. It uses no IdleGPU token, creates no customer jobs, installs nothing and awards no badge. GPU compatibility and useful output quality still need a real-device test. Customer dispatch is not enabled for this workload.

Before a marketplace launch, this workload needs independent correctness checks, interruption/retry testing, a reviewed data path, workload-specific verification and an agreed acceptance rule.

Common questions

Can I upload a Blender scene now?

No. The first research runner creates its own fixed scene. Arbitrary customer scene files, external references and scripts require additional isolation and validation before they can be offered.

Does the embeddings badge cover rendering?

No. Workload qualification is specific to the tested software and operation. Rendering needs its own compatibility, correctness and reliability evidence.

Will Blender rendering work on every NVIDIA GPU?

No universal compatibility is claimed. The existing Blender build must expose a working CUDA or OptiX device; the runner stops if the selected backend is unavailable.

Explore related GPU workloads

Text embeddings → GPU image processing → GPU audio transcription →

Compare workload scope and readiness →

Blender Cycles GPU rendering documentation ↗