Blender Edit Mode Performance

I have been only using Buildbots of Blender since shortly after the 2.80 release when all the new outliner features got added. Buildbots are generally stable enough that it’s just worth using them for the new features :slight_smile: Looking forward to 2.82 alpha!

1 Like

Nvidia; The way you are meant to create. This will remain true until AMD can ensure their drivers can just work in new Blender builds without waiting for fixes from the dev. team. Though in this case they can’t do much about cards that AMD stopped supporting.

AMD cards can be made to work at least, meanwhile there does not seem to be a lot of promise for Intel’s new cards to function well because the company’s drivers are still awful.

2 Likes

Hi, Intel promise brand new driver on the day of publication for the new GPU´s! :rofl:

Cheers, mib

What is necessary of selection undo. Do we really need it. Undo of selection takes lots of time in relatively 20 objects blend file. Can we remove selection undo in preferences?

I’m a direct victim of these drivers, and even a direct break-up of boxes to the devs to save these GPU…
Apparently these drivers, do not have a real bug, but have the inverted matrix of an API callelling that caused the destruction of the geometries … (from what I seem to guess)
it seems that the Standard has changed at some point and everyone has followed that trail with new drivers, the workaround now seems to work well, but it took a year to figure out where the problem was.

all the more to confirm this, that the problem also appears on linux, probably the guys of the Mesa opensource drivers, considering this category of gpu stable, have not yet noticed this problem and have not corrected “the change over time” …
in fact the work around is also valid for linux.

to make blender work well on these gpus on linux you have to start blender with:
R600_DEBUG=nosb ./blender ----debug-gpu-force-workarounds

600_DEBUG=nosb disable the shader backend acceleration

unfortunately another boring bug afflicts these gpus in linux, and therefore we must sacrifice the acceleration of the compilation of shaders …

and from my suspicion, this shader backend acceleration is plagued by the same “bug” of the inverted matrix calling API somewhere …
in fact the colors of the lights appear inverted enabling the shading backend


That only concerns the OpenXR branch.

no, as it seems to understand, they are became aware of this by trying this openXR branch but it is likely that there are probably other bottlenecks even in the master

Just read it. He says in OpenXR branch even the default cube runs at just 45FPS. There’s nothing in that report which implies that solving the issue would bring any significant performance boost outside of that branch, and it likely won’t.

Both GPU_Draw_List_Init and GPU_Buf_Alloc seem to trigger behavior in the nvidia driver that causes it to spin off a thread and wait for it to exit, not something you’d want to do every frame (or multiple times a frame, hard to tell from a flame graph)

Discussed on chat and you requested a task low prio task for this for further investigation

if this is about the drivers and it’s also in the master I’m right, otherwise you’re right :grin:

If I do Tris ti Quads operation, everything is fine but next time I want to go to edit mode Blender stops responding. It happens only on high poly mesh. In example mine is 1.5 mil faces.

if you think it’s a bug, you should report it ,
best to do it through blender menu --> help -> report a bug

to be real honest im starting to have a real love/hate relation with Blender (especially 2.8). I love so much about this software but the performance is just a HUGE bottleneck. I knew this was the case when I started using it but I do admit im a bit dissapointed that 2.8 seems even more slow then 2.79.
For professional 3D work I simply cannot use Blender anymore due to it being so unstable and slow. I really really want to and firmly Believe that blender could replace Maya if the performance is fixed! :slight_smile:

10 Likes

Sergey’s Patch for Speed up for motion path calculation.

4 Likes

I would wait until October 10, before giving strength to these feelings.
A version, the first 2.80, which is stable but not performing may be is acceptable.
The undo will arrive soon, and as you can see the patch for speedup motion path calculation is in review … a lot about the viewport has already been done. especially optimization in instance management …
These are the things that are most important …

2.81 will not be bad at all in terms of workflow.

They will miss heavy mesh performance and gpu opensubdiv, but for these I think we can wait another release. It will mean that we will use proxies and start testing the new system of overrides (and using 2.82 alpha :joy:)

I’ve been going back and forth between 2.79 and 2.8 so much (mostly because of performance) that I think there should be a 2.8 keymap fro 2.79.

I know there’s a 2.7X keymap for 2.8, but I think any new 2.8 converts that have acquainted themselves in the Blender way of doing things and would like a better performance could give 2.79 a go for the time being, until some of the performance problems get fixed. I’d also rather get accustomed to 2.8 keymaps for when 2.8 becomes fully viable (performance-wise).

1 Like

on review:

Sculpt: multithread GPU draw buffer filling

This multithreads the part of GPU buffer updates that does not do any OpenGL calls. This is the most computationally expensive part on the Blender side, but OpenGL calls may be costly too, we’ll have to see.

Performance not tested yet.


Enable multithreading for multires and dyntopo too.

1 Like

b3d viewport.m4v (4.7 MB) 2.8 Viewport performance is bad in low poly scenes too.

I’m not sure that those numbers reflect the true framerate … blender uses more framebuffer levels, do you think it is logical that with a cube you have a low framerate?
try with search > debugmenu > 21 or 22 or 23 or 24 maybe you get some better statistics.
:wink:

Old hardware?

yes i3,hd 5450,win 10 but Maya 2019 works butter smooth.