For me it works, so I would say yes :)

OK, this seems to be "fixed" with this commit: https://developer.blender.org/rB6899dbef77cd26df3588888040887e4e41c1ec43

Quick update: If I link the collection to a scene and use "Make Proxy" instead of "Make Library Override" everything works as expected...

I just tried to reproduce it and couldn't reproduce the crash anymore. Great work, guys! 👍
This ticket can be closed I guess.

Yes, the build you're testing is older than the release from the Build Bot I mentioned as the last working build. So I would expect that to work as well, as the bug seems to have creeped in at a later time (most likely here I suspect https://developer.blender.org/rBbb2af40ec7dd9a0c41991bc2faaf6eb3f0618016 ). If you're not compiling Blender yourself, you might have to wait a few hours until an updated build is available for download.

Thanks! I can confirm the fix is working for me!

Yeah, right! At first it looked too easy because I didn't notice that Denoising Data was enabled and I could easily reproduce it with an empty scene file (which I assumed was a bit stupid to upload). But in the end it would've helped.

And just to confirm I just downloaded today's Buildbot build and it fails the same way as my own build yesterday. So it's not a CUDA 10 vs 11 thing. ( blender-2.93.0-41a945d7469f-linux64 )

OK, a quick update:

Hmm, I'm using CUDA 11.2 on my side. Maybe that's the problem.

Thanks for testing YAFU. I don't mean progressive refine but normal tiled rendering with GPU+CPU (CUDA+CPU).
The OptiX and progressive part of that bug report comes from the commit that caused the crashes for me ;)
I also build with OptiX 7.2.0

Invalid value in cuMemFree(mem.device_pointer) (device_cuda_impl.cpp:970)
Launch failed in cuMemcpyDtoH( (char *)mem.host_pointer + offset, (CUdeviceptr)mem.device_pointer + offset, size) (device_cuda_impl.cpp:1034)

Thanks a lot! Problem is fixed :D

I close the file browser by clicking on "Cancel" in the lower right corner. I set my file browser to open fullscreen, maybe that might make a difference?

I just gave it another try with the very latest master and the problem still looks the very same. I attached the system-info.txt from this version here.

I applied Lukas' patch and it works perfectly. It just needs to get reviewed and accepted.

Now that NanoVDB is enabled by default, this bug will hopefully be confirmed as soon as the Buildbots are updated tonight.

Thanks for fixing this crash. It was gone after your commit, but now with the latest master it seems to be back :(

I restarted everything of course, not only Blender. Maybe it's hidden somewhere in a GPU cache or whatever. It happens with all kinds of builds (official and my own). At first I thought it might be a problem with me using CUDA 11 to compile blender, but also the official master builds show that problem.
Your setup indeed looks very similar to mine.

Great! Thanks. So far it's looking good. I'll report back as soon as something weird happens.

What caught my eye when giving this scene a try was that your hair rendering geometry was set to:

Just gave this scene a try and it renders without problems here:

Nice! Good to hear that I'm not the only one ;)

Thanks for investigating.

Oh damn, didn't see that one. OK, so I guess I'll have to live with it then.

I have been able to bake normals, if I used Particle Instance modifier on cube, and then baked cube to target, which is essentially what you did, but a bit more procedural. Perhaps this was also a method that worked prior to 2.8?

Sadly no, it seems.

@Brecht Van Lommel (brecht) Thanks for taking care of this so quickly.

Ah sorry, you're right. I can confirm the bug with the current master:
version: 2.90 (sub 0), branch: master, commit date: 2020-04-21 16:29, hash: rB8845b27dce89

This functionality was added during the 2.83 alpha phase AFAIK. So no chance to test it in 2.82a.
The bug itself isn't fixed in the latest builds. I'm using the 2.90 alpha right now and it shows the problem.