I just tested with the latest version and with the opengl32 file(which for some reason slowed blender to an absolute crawl. It tool 4 attempts at opening blender to get something that didn't hang up.

I tried using the openGL32.dll. It still renders my normal mapped objects as black, just very very slowly. I'm on Windows Pro 64 bit with a GTX 1050.

This reveals a big issue. Everything in the batch cache is done right but the tangent layers are not updated / generated when doing this switching.

We added a hack to make it work when switching using the buttons and I can add the same hack to the operator too. This would fix it for this case but not the case of multiple viewport.

The hack comment reads :

		/* XXX Dependency graph does not support CD mask tracking,
		 * so we trigger  materials shading for until it's properly supported.
		 * This is to ensure material batches are all recreated when switching
		 * shading type. In the future DEG should replace this and just tag
		 * the meshes itself.
		 * This hack just tag BKE_MESH_BATCH_DIRTY_SHADING for every mesh that
		 * have a material. (see T55059) */

The real issue is that the depsgraph does not know what data to generate because data depends on a lots of things. The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use for this object (or even better, asks if this object is inside an active View or culled).

@Brecht Van Lommel (brecht) @Sergey Sharybin (sergey) What would be the best way to start this work?

@Clément Foucault (fclem), things are.. complicated. Will probably start with the simple answers which i know for sure.

or even better, asks if this object is inside an active View or culled).

This can not be done in the dependency graph. Dependency graph doesn't know anything about viewport, and its main goal is to make sure the scene as a whole is ready for display/use. Doing such culling tests will slow down navigation, and will make evaluation even more complicated (and slowerdue to more checks) to deal with cases when culled object is actually affecting something what is visible.

Maybe (maybe) something we can go into later, but is not a complexity i am looking forward at this point.

The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use

Think we've got quite everything for this: we already do similar thing for the modifiers evaluation (and @Bastien Montagne (mont29) refactored some bits in D4407 which is ready to go in).

The annoying part is that currently those data masks are calculated and checked during relations update. So ideally we would need to separate those masks a bit: store "invariant" masks based on the depsgraph builder, and then have additionaly mask which will gather masks when shaging or viewport changes. And the outer world we will report a combined mask between those.

Is also possible to tag ID nodes which custom data mask changed.

Not sure what would be better: either have an explicit call like DEG_on_customdata_masks_changed_update() or by collecting masks prior to evaluation.
The first approach is annoying since requires an explicit call from all places which would affect the masks.
The second approach is annoying since it can't be easily optimized out by skipping traversal of all ID nodes, so it will be a lot of CPU ticks spent just to see that nothing has changed.

Maybe truth is somewhere in the middle, we will tag dependency graph for custom data masks update, and then actual update is done as first step of evaluation