Official Progressive GPU Lightmapper preview

GPU lightmapper is a preview feature. Preview means that you should not rely on it for full scale production. No new features will be backported to 2018.4, 2019.x or any of the following releases. We recommend using 2023.2 or later because the GPU lightmapper has reached feature parity with the CPU version at this point.
The goal of the GPU lightmapper is to provide the same feature set as the CPU progressive lightmapper, with higher performance.

We would like you to take it for a spin in the latest alpha/beta version and let us know what you think. Please use the bug reporter to report issues instead of posting the issues in this thread. This way we have all the information we need like editor logs, the scene used and system configuration.

Missing features in 2018.3. Most features will be added in the 2019.x and 2020.x release cycles:

• Double-sided GI support. Geometry will always appear single sided from the GPU lightmapper’s point of view. Added in 2019.1.
  
• Cast/receive shadows support. Geometry will always cast and receive shadows when using the GPU lightmapper. Added in 2019.1.
  
• Baked LOD support. Added in 2020.1.0a20.
  
• A-Trous filtering. The GPU lightmapper will use Gaussian filtering instead. Added in 2020.1a15.
  
• Experimental custom bake API. Added in 2020.1a6
  
• Submesh support, material properties of the first submesh will be used. Added in 2019.3.
• Reduced memory usage when baking.

Features added in 2019.1 (will not be backported)

• Double-sided GI support.
  
• Cast/receive shadows support.
• macOS and Linux support.

Features added in 2019.2 (will not be backported)​

• Multiple importance sampling for environment lighting.
• Optix and OpenImage denoiser support.
• Increased sampling performance when using view prioritization or low occupancy maps:
  • Direct light (2019.2.0a9).
  • Indirect and environment (2019.2.0a11).

Features added in 2019.3 (will not be backported)

• Submesh support (2019.3.0a3)
• Match CPU lightmapper sampling algorithm (2019.3.0a8)
• AMD Radeon Pro Image Filters AI denoiser added. Currently Windows and AMD hardware only (2019.3.0a10).
• Added support for baking box and pyramid shapes for SRP spotlights (2019.3.0a10).

Features added in 2020.1 (will not be backported)

• GPU backend can now export AOVs to train ML code for de-noising lightmaps. Only available in developer mode (2020.1.0a1).
• Compressed transparency textures; 75% memory reduction by using rgba32 instead of floats (2020.1.0a2).
• GPU lightmapper can now write out the filtered AO texture to disk, alongside the Lighting Data Asset. Only available in On Demand mode. Only available through experimental API (2020.1.0a3).
• Support for the Experimental custom bake API for GPU lightmapper (2020.1a6).
• Accurate OpenCL memory status for AMD and Nvidia GPUs (2020.1a9).
• Reduced GPU memory usage when baking lighting by using stackless BVH traversal (2020.1a9).
• Show user friendly name in the Lighting window for AMD GPUs on Windows and Linux instead of GPU code name (2020.1a9).
• Compute device can be selected in a dropdown in the Lighting window (2020.1.0a15).
• Limit memory allocations for light probes to fit in available memory when baking with progressive lightmappers (2020.1.0a15).
• A-Trous filtering (2020.1a15).
• Baked LOD support (2020.1.0a20).
• Baked light cookie support (2020.1.0a22).

Features added in 2020.2

• Brought back stack based BVH traversal, this time with with Baked LOD support (2020.2.a1).
• Reduce memory usage when baking large lightmaps on GPU by disabling progressive updates and using tiling on the ray space buffers (2020.2.0a11).

Features added in 2021.2

• Memory and performance improvements when baking Light Probes (2021.2.a17).
• Lightmap space tiling to reduce memory usage (2021.2.0a19).

Supported hardware
The GPU lightmapper needs a system with:

• At least one GPU with OpenCL 1.2 support and at least 2GB of dedicated memory.
  
• A CPU that supports SSE4.1 instructions
• Recommended AMD graphics driver: 18.9.3.
• Recommended Nvidia graphics driver: 416.34.

Platforms

• Windows only for the 2018.3 preview.
• macOS and Linux support was added in 2019.1

How to select a specific GPU for baking
If the computer contains more than one graphics card, the lightmapper will attempt to automatically use the card not used for the Unity Editor’s main graphics device. The name of the card used for baking is displayed next to the bake performance in the Lighting window. The list of available OpenCL devices will be printed in the Editor log and looks like this:

-- Listing OpenCL platforms(s) --
* OpenCL platform 0
PROFILE = FULL_PROFILE
VERSION = OpenCL 2.1 AMD-APP (2580.6)
NAME = AMD Accelerated Parallel Processing
VENDOR = Advanced Micro Devices, Inc.
* OpenCL platform 1
PROFILE = FULL_PROFILE
VERSION = OpenCL 1.2 CUDA 9.2.127
NAME = NVIDIA CUDA
VENDOR = NVIDIA Corporation
-- Listing OpenCL device(s) --
* OpenCL platform 0, device 0
DEVICE_TYPE = 4
DEVICE_NAME = RX580
DEVICE_VENDOR = Advanced Micro Devices, Inc.
...
* OpenCL platform 0, device 1
DEVICE_TYPE = 2
DEVICE_NAME = Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
DEVICE_VENDOR = GenuineIntel
...
* OpenCL platform 1, device 0
DEVICE_TYPE = 4
DEVICE_NAME = GeForce GTX 660 Ti
DEVICE_VENDOR = NVIDIA Corporation
...

You can instruct the GPU lightmapper to use a specific OpenCL device using this command line option: -OpenCL-PlatformAndDeviceIndices <platform> <device index>
For example, to select the GeForce GTX 660 Ti from the log above the Windows command line arguments to provide looks like this:

Code (csharp):

1. C:\Program Files\Unity 2019.1.0a3\Editor>Unity.exe -OpenCL-PlatformAndDeviceIndices 1 0

The card used for Unity’s main graphics device that renders the Editor viewport can be selected using the -gpu <index> command line argument for the Unity.exe process.

If an OpenCL device is ignored for lightmapping, for instance because it has too little memory, it will not count when specifying device index on the command line, so you have to subtract the number of ignored devices from the index yourself.

Things to keep in mind

• 2019.2 and older releases will have sampling and noise patterns slightly different than what is produced by the CPU lightmapper as the sampling algorithm used is different. 2019.3 and newer is using the same sampling algorithm as the CPU lightmapper.
  
• If the baking process uses more than the available GPU memory the baking can fall back to the CPU lightmapper. Some drivers with virtual memory support will start swapping to CPU memory instead, making the bake much slower.
• GPU memory usage is very high in the preview version but we are optimizing this. In 2018.3 you need more than 12GB of GPU memory if you want to bake a 4K lightmap.
  
• Lightmapper field must be set to Progressive GPU (Preview). Please refer to the image below for how to enable the GPU lightmapper.

Linux driver setup
For Intel GPUs, install the following package:

Code (CSharp):

1. sudo apt install clinfo ocl-icd-opencl-dev opencl-headers

And https://software.intel.com/en-us/articles/opencl-drivers#latest_linux_driver
Do NOT to install `mesa-opencl-icd`, even if Mesa is used as Intel GPU driver normally as this driver doesn't work.

When is it ready?
We removed the preview label in 2023.2.0a6.​

 

It is too early to say, it isn't stable enough yet.

 

This is unrelated to baking lighting on the GPU, but rest assured that the task is in our backlog.

 

Thanks, we'll look into that. Fall back to the CPU lightmapper happens if something goes wrong during baking. What is the case number?

 

Hi,
We are aware of this issue: https://issuetracker.unity3d.com/is...ot-available-when-baking-with-gpu-lightmapper
We'll do our best to fix is as soon as possible.
Thanks for your contribution!

 

You can select the device that will be used for baking using -OpenCL-PlatformAndDeviceIndices <platformIdx> <deviceIdx>. The list being printed in the Editor log.

Check the first point of the 'How to select a specific GPU for baking' section in the initial post. However as you state if would be preferable if the gtx1070 would be selected by default in that case. Would you mind open a bug in that regard?

 

When you have two GPU, the one NOT used as the primary device (ie Unity Editor rendering) will be used for baking automatically. Please take a look at the 'How to select a specific GPU for baking' section of the initial post above.

 

Really depend on the scene. If occupancy of the lightmap is good enough and lightmap themselves are large enought you should be closing in to 100%.

As an example:
If lightmap resolution is 2k for example and occupancy is around 70%. It will mean we load the GPU with jobs of (2048*2048*0.7 =) 2.9 millions texels witch should give a good GPU load.
On the other hand if lightmap resolution is 512 and occupancy is 40%. It means we process 100k texels at a time witch will probably not be high enough for a good GPU load.

 

It is in the plan.

 

Hi! Can you please elaborate a bit or perhaps make a bug report if you think there is something completely wrong with directionality in your scene? The GPU and CPU lightmappers are using the same definition of directionality so they should look the same. The Unity directional lightmaps aren't based on SH so they will look different than realtime shaded + SH for indirect. So this is not a apples to apples comparison.

 

100% usage, if there is enough work to saturate the GPU. See https://forum.unity.com/threads/gpu-lightmapper-preview.561103/#post-3729007 for more detail. Have a look at the Compute queues in the GPU section in the Windows Task Manager or GPU-Z.

 

The GPU lightmapper is based on AMD RadeonRays. We are working

Might be related to low occupancy in the lightmap, could you take a look a GPU occupancy using https://www.techpowerup.com/gpuz/ ?

In regard to mrays please note that we are actually computing mega `samples` ie the shading of the texel is taken into account. Thus it will be lower than what you see adverticed as raw intersection performance in AMD RadeonRays or DXR.

 

GPU Progressive Lightmapper is what we presented at GDC and are talking about here. It is currently using RadeonRays GPU compute based ray tracing. Further down the line we will support hardware ray tracing APIs. We are currently working on the low level parts of that.

 

Can you share a screenshot of the incorrect lighting results in the thread. Usually just from that we can make an educated guess about what to do about it.

 

Can you provide your video card driver id before and after please?

 

This is unexpected, are you positive it bake on the GPU ? At the bottom of the lighting setting windows it should show the name of the GPU currently used when doing so.

 

The clustering phase is part of the realtime GI system, this is not using the GPU. This phase runs if you have lights that are realtime with bounce or a realtime environment. Only baked GI is supported by the GPU.

We have no current plans of moving the current realtime GI system to the GPU.

Cheers,
Jesper