GPU vs CPU rendering is the first hardware question after you plug in PBR maps. The materials do not change: albedo, roughness, normal, and metalness mean the same thing. What changes is how fast the path tracer walks the scene and how much texture you can hold at once. This comparison is for Blender Cycles, V-Ray, Corona, and similar offline engines—not for a game viewport.

What each device is doing

A path tracer shoots rays, evaluates BSDFs, and samples textures. GPUs run thousands of those paths in parallel. CPUs run fewer, wider threads and can address system RAM instead of a fixed VRAM pool. For a furnished apartment with 2K wood and concrete, the GPU almost always wins on wall-clock time. For a city block with 8K unique facades and heavy displacement, the GPU may never start.

Quality is not “CPU is more physically correct.” If both engines implement the same PBR model, a converged GPU frame and a converged CPU frame should match within noise. People remember old GPU limitations (missing SSS, weaker caustics). Check your engine version before you assume the card cannot do a material. What a render is: the render process explained.

VRAM is the real GPU limit

Every PBR pack is several images. Ten unique 8K materials is not “ten textures”; it is forty-plus 8K images plus geometry, BVH, and framebuffers. That is how a 12 GB card dies on a “simple” interior. Fixes in order: use 2K on anything that is not a close-up, pack ORM, instance repeated chairs, and disable unused height. Guides: resolution and packing.

Format also matters. 32-bit EXR albedo is wasted VRAM. Keep masters as PNG where 8-bit is enough: EXR, PNG, JPEG. Download only the resolution you will render from the Locker3d library.

When CPU is the right button

Use CPU when the scene is larger than any card you own, when you batch overnight on a many-core workstation, or when a specific effect is CPU-only in your build. Render farms still bill CPU-hours; a GPU node is faster per dollar only if the job fits. Hybrid modes (CPU+GPU) exist in some engines; they help if the extra cores feed a card that is not already saturated, and they can complicate drivers. Test one frame before you commit a 400-frame animation.

Laptops with a weak GPU and a decent CPU should lookdev on GPU at low res, then final on CPU if the card thermal-throttles. Optimization checklist: render time optimization tips.

Engine notes without myths

Cycles: OptiX or HIP/Metal on GPU is the default for stills; CPU remains a fallback. V-Ray: V-Ray GPU is strong for archviz; some features still prefer CPU—read the current Chaos list, not a 2018 forum post. Corona: historically CPU-first; GPU options have expanded, but many studios still finish on CPU because their scenes and LightMix habits live there. Denoisers (OptiX, OIDN) change the sample count you need on both devices: denoising.

A practical decision rule

If a 2K test frame fits and is quiet at a reasonable sample count, stay on GPU for finals. If the GPU render crashes or starts swapping, shrink textures before you switch devices. Organize maps so you can swap 4K for 2K without hunting: organize your texture library. Lighting that needs fewer samples also “upgrades” a small GPU: HDRI lighting setup.

Locker3d maps are CC0, so you can legally create smaller working copies for GPU lookdev. More articles: blog. Metal and stone tests: metal, stone.

Frequently asked questions

Is GPU rendering always faster for PBR scenes?

When the scene fits in VRAM, usually yes. When it does not, CPU can be the more reliable finish.

Do PBR textures look different on GPU vs CPU?

They should not. Differences are usually sampling, denoiser, or a feature gap—not the maps themselves.

How do I stop GPU renders from running out of memory?

Smaller maps, packed channels, instances, less displacement. Switching to CPU is the last step, not the first.