The commit message should be "mesh lights" instead. I should have reused the description in the review which is way more accurate of what this actually does.

Shall I push this then?

I'm testing this in a very simple file with an emitting suzanne mesh and a diffuse plane on the ground but I can't see any performance difference. Probably it's not worth submitting but will leave here just in case it's useful somehow.

I can't be 100% objective since I've worked on facemaps, but this feels, smells, barks and looks like facemaps. In fact I came here expecting to see the code reusing them and was quite surprised that it didn't.

Is it possible to capture the render state with something like Renderdoc? Might give you a few hints.
If you haven't tried it already, it might be an issue with alignment of the data in the indirect buffer (wild guess though).

Looks like a duplicate of T69070 but will leave it up to triage to determine

Thanks for letting me know. I'll leave it up to you guys

Updating to latest driver fixed the delay here. This can surely be optimized better but it's not a blocker any more and it Works On My Machine (tm) now, so it will be up to you guys to improve this if you want.

Put some backwards compatibility in the mix, and this becomes a nice headache problem ;)

Made some changes to my comment because even my own brain was printing parsing errors after reading it.

Hey Brecht, the problem here is converting from scene units (depth buffer to world space that we use in the shader will be in scene units) to the units used internally by the camera. More specifically we are interested in "what percentage of the camera sensor is covered by the circle of confusion".

Well, you can also go to blender installation folder, open a command line on that directory with shift-right click and the relevant command and enter then blender -R in the console.

More comments...

One thing to keep in mind: derivatives are not well defined if there are conditionals in the shader execution leading up to the .evaluation of the derivatives (For instance, read http://hacksoflife.blogspot.de/2011/01/derivatives-ii-conditional-texture.html). The cycles node system allows arbitrary code to run in order to evaluate uvs, therefore you might fall into issues with that. You may be able to hardcode this into some node (for instance, the UV node itself), and this would work much better.

I'm afraid I'll have to agree that this is indeed not a bug - it works as intended so I will be closing this.

Generally if the units were right everywhere (and from what I remember they are not...) scene scale is applied to all lengths in the scene, and then the geometry should not change and the focus would be the same. The crappy thing here is that some parameters from camera are always assumed to be in one unit (mm) which should not change with scene scale probably. On the other hand, the whole point of the focus is to keep, well, things in focus, so this should work regardless of the units of the scene.

Found the bug report:

Hey @Jon Denning (gfxcoder), check if upgrading your Mesa package resolves this. There was a bug in old Mesa which was exactly this (VBO + selection = crash) and fixed two years after we reported it :). I think it was sometime in 2014/2015 which is when your implementation came out, so there's a chance latest versions are fine.

Committed in 861616bf693b78b070ada6cbc6aa79eb807fdde8 thanks for the patch

Can you rebase this against master? I'm getting some errors here

LGTM

Aaaah, indeed you're right. Thanks for fixing, Brecht.

As always for best results we would need a render target to store screen space normals.

It's probably caused by different implementations of dfdx/dfdy functions. You might be able to get rid of some of those by introducing some more bias to the AO effect, but you'll have to test it on the GPU with the issue to make sure it works.

Note - if you comment this out, you'll probably be able to sculpt normally but your normals will be wrong in non-optimal drawing. The change is very subtle, you might miss the error unless you expect it, it should be apparent there. Try GLSL mode it should appear there.

cdDM_update_normals_from_pbvh makes sure normals are updated even when we don't use optimal drawing from pbvh. It basically flushes the changes from PBVH to the derivedmesh itself. It's mostly useful on non-solid draw mode or when we can't do optimized drawing with PBVH (check can_pbvh_draw function)

Actually, I agree with @Brecht Van Lommel (brecht), using BLI_polyfill_calc might be the way to go here.
It just needs to be called after every edit. Maybe we should test how well that works first?

If artists find the old behaviour still useful then I guess it's fine to keep. Added some inline comments.