@Brecht Van Lommel (brecht) that plan looks sound to me.

I just tested out a scene with some heavy geo/higher object count I've been working on in 2.82. Normally it's been taking 20~ seconds to undo an object movement/non Edit Mode stuff.

We have enough complex production files for testing at this point. The most important way to help now is finding bugs where things crash or corrupt .blend file, which any user can help with by enabling the experimental undo speedup option, and then reporting bugs to the tracker that explain how to redo the problem.

Unfortunately I cannot share work assets, but I do have a pretty heavy personal Mech project I have been working on that Undo has been fairly slow on. It uses a lot of booleans and subdivs with creasing.

Short term I suggest to do the following:

• Get artists at the Blender Studio to enable this option and test it.
• Clear common runtime fields for writing. Particularly runtime members and id->tag.
• Before undoing, do an undo write to replace the current state on the stack. Then if that is functioning, we can set accurate is_identical(_future) and only read changed datablocks. I would do this for performance, but also because I'm not entirely sure the current code will give correct results in all cases.
• Do more extensive testing ourselves in production files and get a list of reproducible bugs, and try to fix them.

Looking into the current state I found a few issues. Some require potentially deeper design changes to get maximum performance.

I used Radeon 20.3.1 drivers (latest). Note that all three version (as per origianl post) were done on the same system, so not a driver issue. eager to test that workaround when its out.

@Grzegorz Wereszko (Prodeous) can you upload the system-info.txt generated from blenders' Help menu to this ticket. This file contains information about the driver you are using.

This is caused by MultiDrawIndirect in conjunction with (hypothetically) reading a default non enabled attribute (which should give default color of vec4(0.0, 0.0, 0.0, 1.0)). The attrib is not even always read.

if (materialIndex == 0) {
  color_interp = ac.rgb;
}

My instinct tells me that the driver creates a dummy VBO for non enabled attribs but this VBO is not configured correctly when doing MDI so we get an out of bound read and undefined behavior.

I can reproduce with proprietary drivers on linux. Seems linked to instanced rendering.

Here the problem is evident:

I am not able to reproduce. Using classroom.blend or bmw27_cpu.blend freshly downloaded from blender.org
rB671b6d41c408: CMake: Fix Blender.app creation/modification time Linux Intel

Closing, as this is implemented pretty much to specification.
rB348d2fa09e0c: VSE: Disk cache

I can confirm.
This is a problem in the Workbench, if you switch to Eevee the missing objects reappear.

I can't reproduce a memory usage increase on either Windows or Linux. For me memory usage is about the same with and without OpenCL 2.0.

Great suggestion, @Kenn Nyström (Frozen_Death_Knight)!

Fantastic patch. I have a question though. Are you thinking about adding the ability to do the operations the other way around and generate things like materials, vertex groups, and face maps based on face sets as well? Especially materials I think would be super useful since I liked to block out a model with very basic materials just to get a better idea of how things look in Eevee and Cycles.

Another great advancement, @Pablo Dobarro (pablodp606), many thanks! 👍

In T58473#893894, @Vyacheslav (hitrpr) wrote:

DO WANT this in the nignt-build
Is simething wrong with it? Because it is still not in master.

DO WANT this in the nignt-build
Is simething wrong with it? Because it is still not in master.

• Fix face set rendering with smooth shading in multires

• Enable Face Sets create operator
• Fix bug in undo

Apply Base, Subdivide and Reshape should now be fixed (rBbc0a0cdf171).

@Charlie Jolly (charlie) that's fair, but I think it'd be nice if one didn't have to link the node setup into every new project file. It's more of a convenience node like map range.

Thanks, committed rBd0618570ebea0f68df90c8abd740cf7aa0e3f6d1

@Chris Kohl (ckohl_art) the pointer will remain the same if the object still exists after undo. But it can of course get deleted, so you still can't rely on it.

Thanks @Brecht Van Lommel (brecht) for the quick review!

I'm able to reproduce the issue.

Does preserving/re-using unchanged datablocks/memory mean that this Gotcha will no longer be true 100% of the time? (for data/IDs that didn't change) https://docs.blender.org/api/current/info_gotcha.html#undo-redo

This lock is left out intentionally and there is no actual bug here.