We are still in the 2.8 series of updates, so saying “None of this happened” is false.
Everything just takes time. Subdiv performance needs to be tackled but so do so many other aspects of Blender. Work on one aspect doesn’t negate another, and it’s only a matter of time before these important issues are improved.
Understandable but sub-div is not “just another aspect of blender”. It’s a core functionality and it’s almost unusable for more than a year. Well if they didn’t have time or priority for it they could’ve just hold open-subdiv implementation until it’s ready. Old subdiv worked just fine in 2.8 builds before they replaced it with the new one.
When i said “none of this happened” i obviously was referring to the open-subd related issues. It’s not even about GPU acceleration. Pre 2.8 never had GPU acc. in edit mode, and compare edit mode in 2.79 and 2.8 - it’s like night and day difference. Devs even said they would “bring it back to 2.7 speed” BEFORE 2.8 release. Something is definitely wrong, open-subdiv can’t be so slow by itself.
That’s not true, Subdivision must have been solved before 2.80 like devs told. But like always
maybe better to make new separate build with new slow implementation , and in master build turn back 2.79 subdiv. And remove 2.79 subdiv version from master only when new implementation will be the same speed.
Because it is strange to replace old feature on more slow new version without big advantages.Of course new subdiv have more potential in the future, but maybe need to put in in master only when it works not worse that it was in 2.79? Just my thoughts, maybe I am wrong. I love what developers do , I like that priority for 2020 is undo speedup and speedup for editing high ploy meshes. But subdiv must be also in priority of 2020.
HooglyBoogly I was thinking the same around a year ago, but now need to make something, that why we all write here , so developers can see what is important for users and what is missing in priority .
I hope @dfelinto will see this topic.Thanks.
It is a matter of priorities. There are other more critical animation playback issues that take precedent.
Animators are struggling even when using Simplify at level 0. Having more efficient OpenSubdiv would help with that, but it is something to be tackled afterwards.
But you can keep an eye on that project on: https://developer.blender.org/T68996
As for the highpoly modelling (which indeed is a super important use case), this should be tackled as part of the Edit Mode Performance project.
You can read more details here: T68891 (and I probably will need to close one of these two tasks as duplicated of the other - T68891 & T68996) ).
@dfelinto subdivision perfomance problem is not a problem for animators
Is a problem for
It’s a bigger problem. You only need to see users complaining about this in any part of the program.
Fast SubDs are a standard that’s hard to give up on. Modeling, expression creation, correction shape, playback of any animation, cloth simulation, etc.
The GPU manages millions of triangles without slowing down.
Consider that the SubD in a 3D software are as important as the tomato on the pizza! Thanks!!
To be clear, there are multiple performance projects for 2020:
These all have equal priority and will be mostly worked on by different developers in parallel. High-poly mesh editing and animation playback both are affected by subdivision surfaces and performance will be looked at in the context of both.
Thanks @dfelinto. 
But keep in mind that we are not talking about bad performance just for animation, we are talking also about an over head when rendering for example if we have a highly subdivided mesh, and there are other situations, so it’ snot a matter of animation, it’s a general performance issue that taxes complex scenes with several subdivided objects.
Yeah, for some reason appear that “initialize” the subdivision is really hard. So make a undo, change subdivision,… all that things have a startup time when you use subdivision.
I have the impression-intuition that these three-four problematic systems: undo, slow heavy mesh, animation and subdivision surfaces all have the same “design flaw” and is to keep all data in the scene synchronized during editing or preview playback and this obviously slows down the whole system exponentially… .
Of course it is only an intuition, but I believe that the work that Bastien Montagne @mont29 is doing on the undo system, and that is to consider only the data that must be changed and avoid the recompute of all the other data, will be the key will start the solution of all these problems …
in addition, which obviously for the sake of speed, is to move all the possible on GPU compute, and avoid the continuous swap between CPU and GPU …
(⚓ T60695 Optimized per-datablock global undo)
A lot of the performance regressions in 2.8 seem to be from the actual system rather than the subdivision, so having left the old subd implementation in probably wouldn’t have kept the editing and animation performance to satisfactory level. Optimizing foundation structures is sadly probably going to take some time 
That being said it does just doing some quick testing with suzane subd lv7 disabling and enabling the modifier in 2.79 and 2.83 still seems to be about 2x difference (~2s in 2.79 and 4s in 2.83)
Both play back in viewport at same fps when navigating view. Though, 2.79 has jerky lag at the beginning of the moving which is not in 2.83
2.83 is way faster actually selecting the object, though, 2.79 hangs for a really long time when selecting the monkey.
2.83 fps is about double 2.79 with the use opensubdiv toggled, though, which gives me hope.
Well sucks that we will have to wait months to a year to begin to start seeing similar or better performance as 2.79 for production scenes, though.
When the mesh is animated (shape, bones, cloth etc.) and the SubD modifier is active, the speed of Blender 2.79, Maya, C4D is 100 times faster than 2.82.7. I showed it clearly in the 3 comparative videos. Who makes character animations can not wait another year! SubDs need the GPU.
Take a test with an animated mesh! High levels of division = more speed difference between Blender 2.82 and Blender 2.79 (and all the other 3D software). A huge difference!
Another test, with a character:
Blender 2.82.7
SubD level 0 = 50 fps
SubD level 2 = 3 fps
SubD level 1,2,3 on Blender 2.79 and other 3D software 50 fps or even faster!
Any news on this side? It’s hard to model with this low performance while editing relatively low poly mesh with subd modifier on. Of course i can turn modi off in edit mode, but for tweaking the final shape you need to be able fast tweak vertexes with subd modifier on.
Please give us more performance on this side. In 2.79 it was already very good for my taste.
This is a fundamental feature beside of undo and multires !
I’ve read most of this thread to understand how subd is slow. From the video and report, if subd is disabled it’s about as fast as 2.79b.
I would not recommend to use the feature as “production ready”, it’s kinda broken. When SUBD where introducted years ago, it was only used in the render and on “still frame” not animating.
It’s still possible to work with it off. Still not as convenient as other packages. There still work to be done on this before it’s performance reach production levels.
A possible solution that devs could investigate (if I’m right about this 
), would be to “cache” (use a mesh that is created once with the proper bones influences) instead of subdividing the base mesh and applying the bones influence at each frame (that look the current process for me by looking at the videos).
Anyway, I don’t think that mesh subdivision level on the subd could be animated. If it’s the case, then each version of the mesh should be processed and kept in memory (LOD?).
Doing it once should accelerate the playback performance. When using the “play” button there must be a minimum of things that are processed. Subdividing a mesh while doing this (or processing things with OpenSubD) is killing performance.
