Bad performance with texture painting depending on multi-thread settings
Open, NormalPublic

Description

System Information
Windows 6 64bit, Nvidia Quadro K4000

Blender Version
Broken: Newest official 2.78c (hash e92F235283)

Short description of error

The more I have threads enabled, the slower the texture painting performance is.
I get best performance when setting the threads manually to 1, from render settings.
Maximum I can have is 24 threads.

Exact steps for others to reproduce the error

Make a cube, unwrap, make new image (4096 x 4096), enter texture paint mode, start painting.
Go to render settings and experiment with different thread settings.

My other possibly related settings:
Window Draw Method: Triple Buffer
Region Overlap enabled

Details

Type
To Do
Dalai Felinto (dfelinto) triaged this task as Incomplete priority.May 22 2017, 3:38 PM

Please attach a sample file as per the bug tracker instructions.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

I have the same problem.

System Information
os: Windows 10 64bit,
cpu: ryzen 7 1700,
gpu: amd rx480,
ram: 16 gb ram

Blender version:
2.79

Short description of error:
The performance will drop during texture painting on 3D view port if auto detection of threading is on.
The stroke will become laggy after several stroke. If I change the thread to 1, the performance will restore.
In addition, I change my threads manually, the lower number of threads, the better performance is.
P.s. threads:1 is the best and smooth.

Exact steps for others to reproduce the error:

Make a cube,
unwrap,
make new image (1024x 1024),
enter texture paint mode in 3d view port,
painting.
stroke become laggy after several stroke

File of my setting:

thanks.

Bastien Montagne (mont29) raised the priority of this task from Incomplete to Normal.Dec 30 2017, 11:45 AM

Yeah… threaded code of texpaint should probably be re-written, it’s not even using our scheduler, but launches it own set of threads.

And as we learned recently in another area (mesh normals computation), the more threads you have, the harder it is to get good results unless you manage to have totally lock-free code…

Will see if/when I can tackle that, but this is a TODO really, and am afraid this is not a top-priority task, for now I may just add an hard limit to the number of threads launched by that code (probably between 2 and 4 ?).

Bastien Montagne (mont29) changed Type from Bug to To Do.Dec 30 2017, 11:46 AM

Also… I cannot reproduce the issue here with current master nor with official 2.79 release (linux64bit, 8 threads, also tried forcing to 48 threads with no issue). So could be a problem specific to windows threading implementation… Can you please check in your system monitor whether all or some of your CPU cores are fully occupied when you paint and it becomes laggy?

Also… I cannot reproduce the issue here with current master nor with official 2.79 release (linux64bit, 8 threads, also tried forcing to 48 threads with no issue). So could be a problem specific to windows threading implementation… Can you please check in your system monitor whether all or some of your CPU cores are fully occupied when you paint and it becomes laggy?

Thank you for your prompt reply.
Here is the print screen for your reference.

Yep, so cores are from from fully occupied, which indeed hints at wasted time in locking…