Official Progressive GPU Lightmapper preview

Hi.

I'm testing Unity 2019.4.2 with a MacBook Pro with a Radeon Pro 5300M (4Gb) GPU and a Radeon RX 580 (8Gb) eGPU. Unity is never using the eGPU, but always the GPU. I've tried selecting the 5300M in Preferences/General/Device to use, I've tried adding -OpenCL-PlatformAndDeviceIndices 0 3 in Unity Hub/Advanced Settings (in the editor.log, the RX580 is OpenCL platform 0, device 3) but this is never used, as stated by the same log :
-- GPU Progressive lightmapper will use OpenCL device 'AMD Radeon Pro 5300M Compute Engine' from 'AMD'--
use -OpenCL-PlatformAndDeviceIndices <platformIdx> <deviceIdx> or -OpenCL-ForceCPU as command line arguments if you want to select a specific adapter for OpenCL.

Any idea ?

Thanks.

 

Thanks, With Platform 0 device 2, it works !

 

Radeon Pro Denoiser on Mac, when will this be ready?

 

I doubt any time soon since game dev on Mac is not very popular.

 

I hope It's not a popularity issue, I'm asking for feature parity between windows and mac versions.

 

Short question: Does the baking cost increase linear or exponentional if the lightmap size is increased?
The same scene under the same conditions have this estimated time for me:
256 px lightmap = 30 minutes
512 px lightmap = 4:30 hours

 

Thanks for sharing the plan, I already have a radeon 7 running well, do you mean mac team recources are needed for the mac silicon transition?

 

Well Actually I have a GTX 750 Ti with 2G, but for the latest version of unity this is still insufficient. Actually it wouldn't perform GPU operations with lightmapping anyway even with previous versions. Thinking about upgrading my videocard to a GeForce GTX 1660 Super with 6G. Seems to be the best Budget option. But if there are better options around 200$ I would like to know!

 

So, now the minimum GPU Memory requirement is 4Gb? Because I remember testing GPU Lightmapper with my old GTX 960 (2Gb) and it worked. But now I have these errors:


OpenCL GPU device GeForce GTX 960 from NVIDIA Corporation has less than 4 GB of global memory, ignoring device for lightmapping.

Failed to find a suitable OpenCL device, falling back to CPU lightmapper.

OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_INVALID_PROGRAM

 

Hi, I found that Unity 2020.1.2f1 + GPU Lightmapper has some of memory leak for baking multi-scenes.

Here is log (part of):

 

Posted this elsehwere but got no responce, hopefully someone here can help.

I'm constantly running into an issue where I have to restart Unity because the lightbaking get's stuck on "preparing to bake". I maybe get three bakes at a time before this happens. It's an absolute nightmare and killing productivity. I'm on the latest 2019 LTS, which I was thought was meant to be production ready. This also causes Unity to freeze when I try to close it, having to do a force close.

 

For various reason, it is not easy to file my project to bug report. But I found that disabling "Progressive Updates" in lighting settings makes the issue gone. (Also I baked lightmaps via batch mode)

 

To Unity, thanks for the Progressive GPU lightmapper, keep up the good work!

Suggestion: Please add a notice to users in Unity 2019 LTS that multiple Light Probe Groups with the Progressive GPU should be avoided, since you're not going to backport the light probe group memory optimization introduced in Unity 2020. A single hint somewhere near the allocation error message or in the Lighting window could save developers hours or days of work.

Reason: I wasted days trying to figure out why the Progressive GPU lightmapper failed to allocate memory in my scene, using an 8GB GeForce 1070 and 16GB of system memory. I tried to tweak the lightmapper settings, bit by bit, install new graphics drivers, install old graphics drivers, use Progressive CPU (but it's way slower and hurts iteration time). I read through all the release notes and found that there was a memory optimization regarding Light Probes in Unity 2020.1. I tried upgrading to Unity 2020.1 but that introduced a whole new bag of issues (unrelated to the lightmapper) so I had to go back to Unity 2019.4.5f1 until those are resolved. I crawled through every post I could find online, and finally stumbled across a few posts that hinted at moving all the light probes to a single light probe group. I tried it, and bam, it worked!

Thanks again, keep on improving!

Jonas

 

That seems a very strict pipeline, is there a way to merge multiple probe groups into one using scripts?
@KEngelstoft

 

Yeah, it's strict. In the project I'm working on there's been light probe groups in prefabs before, and those prefabs have been used in multiple locations in the scene (think houses). With this new knowledge I'm going to use one light probe group per scene instead.

It's my understanding that they can't backport the memory improvements to 2019, because 2019 is sort of "locked" and in LTS mode now. I guess only showstoppers and big bug fixes will be addressed in 2019.

EDIT: I wrote an editor script that merges all light probes into one single light probe group. Either extract the attached zip file into your Assets folder or copy paste this code:

Code (CSharp):

1.  
2. using System.Collections.Generic;
3. using UnityEditor;
4. using UnityEngine;
5.  
6. public static class LightProbeGroupMerger
7. {
8.    const string MergedLightProbeGroupName = "MergedLightProbeGroup";
9.  
10.    [MenuItem("Tools/Neuston/Merge Light Probe Groups")]
11.    static void MergeLightProbeGroups()
12.    {
13.        var lightProbeGroups = GameObject.FindObjectsOfType<LightProbeGroup>();
14.        if (lightProbeGroups.Length > 1)
15.        {
16.            // Collect light probe positions from all light probe groups in the scene.
17.            var mergedLightProbePositions = new List<Vector3>();
18.            foreach (var lightProbeGroup in lightProbeGroups)
19.            {
20.                foreach (var lightProbePosition in lightProbeGroup.probePositions)
21.                {
22.                    mergedLightProbePositions.Add(lightProbeGroup.transform.TransformPoint(lightProbePosition));
23.                }
24.            }
25.  
26.            // Create a new light probe group that merges all the light probe positions.
27.            var newGameObject = new GameObject(MergedLightProbeGroupName);
28.            Undo.RegisterCreatedObjectUndo(newGameObject, $"Created {MergedLightProbeGroupName}");
29.            var mergedLightProbeGroup = newGameObject.AddComponent<LightProbeGroup>();
30.            mergedLightProbeGroup.probePositions = mergedLightProbePositions.ToArray();
31.  
32.            // Destroy the old individual light probe groups.
33.            foreach (var lightProbeGroup in lightProbeGroups)
34.            {
35.                if (lightProbeGroup != null && lightProbeGroup.gameObject != null)
36.                {
37.                    Undo.DestroyObjectImmediate(lightProbeGroup.gameObject);
38.                }
39.            }
40.  
41.            Debug.Log($"Merged {mergedLightProbePositions.Count} light probes from {lightProbeGroups.Length} light probe groups into '{MergedLightProbeGroupName}'.");
42.  
43.            Selection.activeObject = newGameObject;
44.        }
45.    }
46. }
47.  

 

*EDIT* Turns out OpenCL was not enabled, used GPU-Z to check, reinstalled drivers and it is enabled now. I think the Editor could relay this info to the user, not everyone is going to troubleshoot it, they will just accept that it is slow or stick to Enlighten, which might be fine.

Still not sure why the initial CPU bake took a long time (never ended actually, using a plane and a cube, I had to cancel it after 20 minutes).
I tried another bake with CPU and it took 6 minutes & it finished that time.
The GPU baking is working now that GPU-Z shows OpenCL as activated. So the same test scene takes 7 seconds.

--

Having some odd results with 2020.1.0f1, on latest nvidia drivers with a 970 (Win10)

Attempting to use Progressive GPU always falls back to CPU with GPU Baking Device "Unknown"

The CPU bake takes an incredibly long time using a simple test scene consisting of 1 plane and 1 cube, both set to static. Direction light set to mixed, Lighting Mode set to Subtractive. Default Lightmapping settings.

It takes several minutes and then gets to the Global Illumination phase and count down, then counts back up and has been doing this for ~10 minutes so far.

 

@XRA From my experience with Unity 2019.4.5f1 - if there's an OpenCL error while baking with the GPU, subsequent bakes will not work properly (it'll bake forever). I have to restart Unity to get it working again. I haven't bothered to report it, as I assume they're not going to look at 2019 anymore (which I use). But since you're experiencing this in Unity 2020.1 it seems to be there as well then.

 

@Jonas-Neuston thanks for the reply, yea it seems like that was the case.

Unrelated, has anyone seen these blocky artifacts in their lightmaps before? (Both GPU and CPU exhibit these)
Compression is disabled and tried different denoiser settings & multiple importance sampling. I can't get a good bake because of the large blocky areas that form all over the lightmap.

*EDIT* I see what it is now, if there is one-sided geometry, if the backfaces (opaque material with culled backfaces) point toward other lightmapped surfaces, it will cause these artifacts if any bounces hit those culled backfaces.

 

Hello,
After I go over most of pages and trayed every solution you guys said,
the only thing that fixed my opencl error falling back to cpu lightmapper is to install the Beta 2020.2.0b4

hope that will help

Windows 10 64bit
I7 5960-X
2070S RTX 8GB
32 RAM
***
EDIT: sorry the problem is still there.(Unity come back to CPU bake and crashed)

 

I opened an old project with the latest unity 2020 series. If I remember correctly I created it with the 2018 series? I noticed that I had used multiple probe groups and baked them successfully with the GPU lightmapper.

Ever since this has not been possible because GPU lightmapper just stops with an error.

Is this not possible to be fixed? Maybe it has been explained somewhere in this thread, but I'm just wondering.

 

For anyone with a Nvidia 3080 series card, You might get an issue when trying to use the GPU lightmapper if you are using the very latest nvidia drivers. I had to revert to the release version 456.38 and then Unity recognized the card as valid to bake with

 

I need to generate 4k lightmaps (and probes) using GPU progressive in Unity 2019.4. Looks like a video card of 12 GB is the minimum on that case, is that right? Which graphics cards do you guys are using for that? (I want to be sure that I will have no issues with the graphic card)

 

This fixed OpenCL problems for me with my 2070, thank you so much.

 

Maybe a stupid question, but I was curious why the Progressive Lightmappers does not first converge all lightmaps and then starts baking them. Is it a Memory issue? Or perhaps context switching?
It seems the Lightmapper still bakes one lightmap after another and especcially in large scenes you want a bigger lightmap resolution to see the final result. I'm always frustrated that the "Prioritize View" does not work when the Lightmap resolution is not fitting on only one lightmap and it's sorta step back from the otherwise very iterative workflow.

 

When i use the GPU Preview it gives me weird things on my light map

 

Unity 2020.2, and:

OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_NDRANGE_KERNEL on GeForce GTX 1080 (Device 0).

OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_MEM_OBJECT_ALLOCATION_FAILURE

GTX1080 8GB, nvidia drivers 456.71

EDIT: Nevermind, dropping lightmap size 2048 -> 1024 fixed the issue.

 

So I'm having this issue for 2 years now, I'm wondering if Unity could at least put an option where the lightmap generation would simply stop instead of reverting to progressive cpu if they have no intention of fixing it really...
Showing how many memory is missing and how much would be nessessary would be great too.

 

I'm having the same issue since GPU lightmapper is introduced and bug was already reported:
- As soon as there's more than 5 or 6 light probes, GPU Lightmapper always fails. The trick of combining them kind of works for some scenes and 1 bake out of 5 (2 or 3 PC restarts required to have 1 succesful bake finally).

Even though my scenes aren't very big, and I have an RTX 2080 with 8Gb VRAM + 32 Go RAM, I can't bake anything except test scenes if there is just a couple of light probe groups.

I don't believe 12Go VRAM can be a realistic minimum requirement; there's definitely an issue with memory when it comes to Light Probes.

This is actually the biggest pain point for our project; GPU Lightmapper working 1 bake out of 10 after at least 3 restarts and clearing baked data manually, and ensuring to re combine all light probe groups before every single bake.

I can confirm our life will be changed forever as soon as GPU Lightmapper can bake with light probes present.

Keep up with the great work, guys, but please look into the Light Probe memory usage as it's really impeding many people ; and there's a good chance that for many people here, their "out of memory" issues are actually linked to that - they just probably didn't try disabling all light probe groups to realize it.

Thanks!

 

Thanks for the info. I'm on 2020.2.1f1, no improvement in my project unfortunately

I remember seeing the release notes mentioning that it's improved. I always switch to latest day 1 just for this issue in case it works better

If this issue is theorically fixed, and maybe no longer investigated, is it worth it for me to try and create a small repro project?

 

Thanks for letting me know! I'm exporting a particular scene with only meshes and Albedo textures to reduce the entire size to around 300mb (instead of 15GB for the project). I will then report from this project to attach it.
As I cannot reproduce in a simple default project, I feel like the only way you can investigate this properly is with the actual scene and I hope reducing to 300mb and set all textures to uncompressed will make the import time acceptable (a few mins) to directly repro easily.
In that repro project, disabling all light probe groups makes the bake successful; any enabled will always result in failure. Will report some time today and post the link here!

 

Hi again! I just reported, here's the case number of the report: 1307489

I'm so excited - thanks for looking into it, our life would be beautiful if it could be fixed, or if you could give us steps to minimize the issue if possible

I'm aware that probably it will be successful with a 32Gb VRAM GPU, but this isn't something we can afford

Whenever there is a fix to test, let me know I'll test in Alpha or Beta ASAP!

Thank you again,
Charles

 

Just a tip:
Don't post links directly to fogbugz, as it may contain personal sensitive information that you don't want to be public. Also, other reported bugs visible through it.

Case Number is enough for Unity Team.

 

Thanks for the info @xVergilx - updated to do so - I made sure to remove anything sensitive but we never know!

 

wait 1070 should be supported by GPU lightmapper isn't? i'm trying to bake HDRP test scene in 2021.1b3 it keep fallbacking to CPU

 

You might be having a different issue or maybe 1070 simply has below 4GB VRAM in which case it isn't really supported, but:

Have you tried to disable or delete every single light probe group in the scene, save then restart Unity and bake again with GPU?

Then, if still not good try reduce lightmap size and resolution.

 

My 1070 have 8GB Vram, it's the built in HDRP Demo Scene and i haven't change anything

 

It should be depending on the available memory. I'm able to use the GPU Lightmapper and I'm running a GTX 1060ti.

 

ah, simply by turning the editor on and off it work again.
I mean restarting the editor