[Bug] AMD Ryzen 9 Cpu 0 always @100%

[MagnusL]

EDIT: ATtached screenrecording of the jittery movement, 100% CPU while moving the mouse in the app. 3DC version 2022.47



Hi. I have searched for this question but didn't find any relevant answer

Using an AMD Ryzen 9 5950x, RTX 2070 Super GPU, fast 4x NvME drives and a truckload of fast Ram i would expect it to chew most 3D apps easily but when it comes to 3DCoat i find the sculptig in Surface mode to feel quite "jerky" and i haven't really thought about checking CPU usage as there is a multi thread option in preferences that already selected all 32 threads.. so i thought all was dandy.. still the "jerky feel" i haven't been able to shake

Opened the performance manager today as i'm getting too annoyed by this jerkyess and found that Cpu 0 is always @100% when sculpting in 3DC, only in Voxelsculpt it's accompanied by other cores.. but still, Cpu 0 is always at 100% regardless which lead me to believe this is something that could explain somewhat why there is a jerky feel to the brush movement when doing fast strokes.  And this is with very low polycount

Zb uses all cores equally accessed.



3DC has all the love for CPU 0

Edited October 12, 2022 by MagnusL
Added screen recording

[AbnRanger]

33 minutes ago, MagnusL said:

Hi. I have searched for this question but didn't find any relevant answer

Using an AMD Ryzen 9 5950x, RTX 2070 Super GPU, fast 4x NvME drives and a truckload of fast Ram i would expect it to chew most 3D apps easily but when it comes to 3DCoat i find the sculptig in Surface mode to feel quite "jerky" and i haven't really thought about checking CPU usage as there is a multi thread option in preferences that already selected all 32 threads.. so i thought all was dandy.. still the "jerky feel" i haven't been able to shake

Opened the performance manager today as i'm getting too annoyed by this jerkyess and found that Cpu 0 is always @100% when sculpting in 3DC, only in Voxelsculpt it's accompanied by other cores.. but still, Cpu 0 is always at 100% regardless which lead me to believe this is something that could explain somewhat why there is a jerky feel to the brush movement when doing fast strokes.  And this is with very low polycount

Zb uses all cores equally accessed.



3DC has all the love for CPU 0

I think it is quite possible that the jerkiness is from REMOVE STRETCHING...when that is enabled in the Toolbar. The reason is, 3DCoat has to perform another calculation once your stroke is finished. It is remeshing locally, on the fly...hence the little pause you might feel. CONFORM RETOPO also does this at the end of a stroke, if it is enabled. Try to leave those unchecked and see if that is indeed the reason.

My son in law has a laptop with an AMD (4800H) 8-core CPU (16GB and an NVidia 1660 and it sculpts like a boss, so I don't think it is an issue with AMD CPU's.

[Elemeno]

omg its true... core 0 maxes out... when sculpting...

it appears to be just surface tools...
which is strange because the tools utilizing one core works smoother than the tools that use 9 other cores...

[MagnusL]

4 hours ago, AbnRanger said:

I think it is quite possible that the jerkiness is from REMOVE STRETCHING...when that is enabled in the Toolbar. The reason is, 3DCoat has to perform another calculation once your stroke is finished. It is remeshing locally, on the fly...hence the little pause you might feel. CONFORM RETOPO also does this at the end of a stroke, if it is enabled. Try to leave those unchecked and see if that is indeed the reason.

My son in law has a laptop with an AMD (4800H) 8-core CPU (16GB and an NVidia 1660 and it sculpts like a boss, so I don't think it is an issue with AMD CPU's.

Thanks for replying and the suggestions, i checked a YT video of an older version of 3DC that has "Remove stretching" in the toolbar
but it seems it's moved ( or removed..?)
i use 2022.042

Conform retopo mesh is not selected by default.

[MagnusL]

New day more discoveries trying to get this app to feel smooth as a baby cheek but it doesn't seem to cooperate very well.
Cleared out my CMOS and set the bios back to stock settings, turned off a few things not needed, no OC whatsoever and no tweaks.

Not sure what to make out of all this but it seems all cores except CPU 0 is slightly more utilized, but could be wishful thinking




Now i turned off most background apps from running, turned off the USB audio card just moving the mouse around (!!?) CPU 0 is having a hard time catching up with the tremendous load lol...  what bugs me is that i can load ZB up, which is heavy app to get going, load it up to the brim with polygons and still it's like cutting warm butter. 

If i only could get rid of the jerky feel having CPU 0 sweating it's balls off wouldn't matter

[MagnusL]

Hi guys.. After diggin around some more i found out that the ASUS ROG Crosshair VIII Mobo M2_1 slot is shared with the upper ( closest to the CPU socket) PCIe16 lane, where i had my Corsair MP 600 drive located and apparently this gave pretty sucky testresults on DiskMark.. so i set out to see if i could get better performance

The MP600 drive is said to handle pretty swift data transfers, but sharing bus with a GPU.. the results speak for themselves... 

Corsair MP600 i M2_1 slot

Went down and purchased a new Kingston Fury Renegade drive today but kept the drive in slot 2_1
pretty dissapointing to loose 3000 mb/s


After shifting things around inside the computer, moved the GPU to a non-shared slot, switched both M2 drives around so the Renegade drive now uses the M2_2 slot and without sharing the bus it looks a lot better.. not sure it's worth it but it's pretty darn quick now

 

Edited September 18, 2022 by MagnusL

[AbnRanger]

On 9/17/2022 at 11:55 PM, Elemeno said:

omg its true... core 0 maxes out... when sculpting...

it appears to be just surface tools...
which is strange because the tools utilizing one core works smoother than the tools that use 9 other cores...

You can bring this to the attention of the developers (support@pilgway.com), but I don't think there is anything wrong with the first core being maxed out. It could be handling the most critical operations and the rest are given secondary tasks. An example might be that the first core has to store Sculpt Layer information on the fly, while the other cores deal with the actual deformation of the vertices + dynamic subdivision, etc.

[AbnRanger]

On 9/18/2022 at 7:22 PM, MagnusL said:

Hi guys.. After diggin around some more i found out that the ASUS ROG Crosshair VIII Mobo M2_1 slot is shared with the upper ( closest to the CPU socket) PCIe16 lane, where i had my Corsair MP 600 drive located and apparently this gave pretty sucky testresults on DiskMark.. so i set out to see if i could get better performance

The MP600 drive is said to handle pretty swift data transfers, but sharing bus with a GPU.. the results speak for themselves... 

Corsair MP600 i M2_1 slot

Went down and purchased a new Kingston Fury Renegade drive today but kept the drive in slot 2_1
pretty dissapointing to loose 3000 mb/s


After shifting things around inside the computer, moved the GPU to a non-shared slot, switched both M2 drives around so the Renegade drive now uses the M2_2 slot and without sharing the bus it looks a lot better.. not sure it's worth it but it's pretty darn quick now

 

Did this help with your specific (brush performance) issue? The guy (Rygaard) who did the Rhino sculpting has an AMD CPU, 5900X (12 cores) and there appears to be no stuttering effect in his sculpts.

 

[MagnusL]

No, the jittery feel is still there. 

[AbnRanger]

6 hours ago, MagnusL said:

No, the jittery feel is still there. 

Can you contact support at support@pilgway.com and explain the nature of this problem? If you could demonstrate it in a screen recording, that would really help them to troubleshoot the issue. Before you do that, try a few things...check the Tool Options panel and make sure JITTER is not enabled (MISC SETTINGS). Also, it would be a good idea to uncheck AUTO-SUBDIVIDE in the Subdivision section of the Tool Panel. At least temporarily, while trying to get to the bottom of this issue.

If those don't help, try one last thing...I used to have an AMD ThreadRipper CPU, and at times I had a similar issue. I switched to an Intel CPU (10900) and had no more issues. So, it is possible there is some sort of CPU thread scheduler issue still, with some AMD CPU's and Windows. I think he went into Windows Task Manager > Details > RMB click 3DCoat.exe > Set Affinity > Uncheck CPU 0

 

[MagnusL]

Hi Abnranger
Much appreciated you trying to come up with things to possibly smooth out the quirk i have.. To clarify the "jitter" i get is more like the brush skips frames and jumps instead of a smoth motion.. Sort of when a buffer isn't written to fast enough or an old severely defragmented mechanic drive.

GPU Load is about 28% when this happens ( RTX2070 Super 8Gb, Drivers updated last week)

I get this when sculpting even in with small brushes / fairly low poly settings for the model.  32Million poly sculpt in Zbrush is as smooth as a babys cheek.. so it shouldn't be any of my components

I still use stock settings on brushes as i'm trying to figure things out to setup 3DC as smooth as possible.. still a few clunky things i have to work out

1. "Jitter" is not activated in any of my tools
2. Auto retopo is not turned on in any of my tools
3. Setting Affinity and unchecking CPU 0 didn't do anything to the issue, but the load on other CPU's got very interresting.. sort of overloading some random CPU's and spiking others

Here CPU0 is turned off, interresting spikes in CPU 12 and 13



Here the same model but just moving the mouse back and forth, i.e not sculpting


 

[phoenixart]

On 9/19/2022 at 9:10 PM, AbnRanger said:

I think he went into Windows Task Manager > Details > RMB click 3DCoat.exe > Set Affinity > Uncheck CPU 0

Thanks for posting that video, although too technical for me to understand it, it's interesting to see that there's indeed some issue related to AMD CPUs, though apparently, not strictly AMD's fault.

I feel my take on this whole AMD experience as I reported here stands true: it doesn't matter if on paper the hardware sounds great. What matters is how well it performs with the OS the user is using. For me, it only means I will go back to Intel for my next build, no more AMD fuss.

[AbnRanger]

2 hours ago, phoenixart said:

Thanks for posting that video, although too technical for me to understand it, it's interesting to see that there's indeed some issue related to AMD CPUs, though apparently, not strictly AMD's fault.

I feel my take on this whole AMD experience as I reported here stands true: it doesn't matter if on paper the hardware sounds great. What matters is how well it performs with the OS the user is using. For me, it only means I will go back to Intel for my next build, no more AMD fuss.

I feel the same way. I had and still am, to a large extent, a big fan of AMD CPU's, but I knew that 3DCoat's multi-threading is based on the Intel Thread Building Blocks (TBB) library. I noticed a big difference in years past, because Intel pulled a dirty trick and hamstinged AMD CPU's (when Intel TBB was used). That was litigated in court, and AMD won a large chunk of change...but I don't know if there is any residual problems from this. Please contact support (support@pilgway.com) and see what Andrew has to say about this. I told him about the issue I had with ThreadRipper and he said he might look at an alternative to Intel TBB, but that would be a huge task.

What is strange is my son-in-law's AMD laptop is buttery smooth when sculpting in 3DCoat...it was outperforming my ThreadRipper even!  

[AbnRanger]

On 9/22/2022 at 7:30 PM, phoenixart said:

Thanks for posting that video, although too technical for me to understand it, it's interesting to see that there's indeed some issue related to AMD CPUs, though apparently, not strictly AMD's fault.

I feel my take on this whole AMD experience as I reported here stands true: it doesn't matter if on paper the hardware sounds great. What matters is how well it performs with the OS the user is using. For me, it only means I will go back to Intel for my next build, no more AMD fuss.

Have you raised this issue with Andrew (support@pilgway.com)? It seems using an Intel Thread Building Block Library could still be an issue.

https://medium.com/codex/fixing-intel-compilers-unfair-cpu-dispatcher-part-1-2-4a4a367c8919

This problem was mentioned almost a decade ago and it may still be a problem.

Can you screen record a test on the default head bust (from the Splash Screen > Surface Sculpting > pick the Head Bust starter object > click the INCREASE RESOLUTION icon at the bottom of the Sculpt Tree panel, to bring it to about 1 million polys (you can see the polycount at the bottom of the UI, in the status bar). I am really curious to see where this issue is happening. I will try to do a similar test on an AMD laptop (4800H CPU) and see if I can replicate the issue. I did a similar comparison between it and the ThreadRipper (1650X) I had and the AMD Laptop was much better than the ThreadRipper, for some strange reason (probably because it was a much newer CPU than the ThreadRipper).

 

[phoenixart]

On 9/27/2022 at 8:57 AM, AbnRanger said:

Can you screen record a test on the default head bust (from the Splash Screen > Surface Sculpting > pick the Head Bust starter object > click the INCREASE RESOLUTION

Thanks for the insights @AbnRanger

I did record a screen session, still feel the AMD is performing slower than Intel.

Granted, my CPU is older than Elemeno's, but it might be related to the core clock speed, or at least, that's why in my case my Threadripper is underperforming in other 3d software too compared to the Intel counterpart.

Here's my screen record:

Edit: I can't post the video, or for that matter neither images anymore. I get a warning of file size limit being 35kb.

 

Edited September 30, 2022 by phoenixart

[Carlosan]

13 hours ago, phoenixart said:

Edit: I can't post the video, or for that matter neither images anymore. I get a warning of file size limit being 35kb.

Sorry but your attachment quota is full

[phoenixart]

Thanks for the info @Carlosan

@AbnRangerhere's the screen record

https://www.veed.io/view/0bd8aaf6-0bb3-472f-94ea-fbf33ab4ea80/showcase?sharingWidget=true

[AbnRanger]

4 hours ago, phoenixart said:

Thanks for the info @Carlosan

@AbnRangerhere's the screen record

https://www.veed.io/view/0bd8aaf6-0bb3-472f-94ea-fbf33ab4ea80/showcase?sharingWidget=true

Thanks, but for some reason the recording lasts about 32 seconds, so I didn't get to see the part where the brush performance stuttered or anything. I am very curious about this because AMD is coming out with a new series of CPU's that can get up to 5.7Ghz with it's own default OC/boost 

[phoenixart]

1 hour ago, AbnRanger said:

for some reason the recording lasts about 32 seconds

I misunderstood, I thought you were interested in seeing that part of the screen record. I'll prep another video. 

But quite simply, in my case, 3DCoast slows down when I'm already smoothing the geometry. It kind of freezes for a bit before the operation is done.

I'll post the video later.

[Sorn]

In case it is relevant to fix the issue:

In a machine with an AMD Ryzen 9 5900X, Core 0 is 100% used when runnung 3DCoat on Windows 10 Pro and sculpting or moving the brush around in Surface and Voxel mode. 3DCoat on Linux doesn't show this behavior.

Tested with 3DCoat 2022.47 and 2022.48 on Windows and 3DCoat 2022.47 on Linux.

Edited October 2, 2022 by Allabulle
It happens in Surface and Voxel modes, actually.

[MagnusL]

I have added a screenrecording of the Jiitery movement and the CPU 0 load. The first few seconds of the video is just moving the mouse around, second part is while moving strokes fast over the object,, seems to affect horizontal movement the most, little less jittery on vertical movement.

This onject is some 1.7 Milion polygons but the jittery issue is not dependent on polygons as it does the same on an object from 50 - 100k polygons

 

Edited October 12, 2022 by MagnusL

[AbnRanger]

15 hours ago, MagnusL said:

I have added a screenrecording of the Jiitery movement and the CPU 0 load. The first few seconds of the video is just moving the mouse around, second part is while moving strokes fast over the object,, seems to affect horizontal movement the most, little less jittery on vertical movement.

This onject is some 1.7 Milion polygons but the jittery issue is not dependent on polygons as it does the same on an object from 50 - 100k polygons

 

I went back and re-read your previous post about this issue. Could you try one last thing? Go to the GEOMETRY menu and de-select INCREMENTAL RENDERING. When you said it was as if it was skipping frames, that instantly made me think of this issue...something I experienced randomly in the past, but multiple times in a given sculpt session. Incremental Rendering is supposed to help performance, but I think it is not noticeable on most newer systems where the CPU, GPU and RAM are relatively robust. I personally leave it unchecked on my end. I hope that helps. If not, please send this video and explanation (how to repeat it) to support@pilgway.com. In the Email title make sure to mention the word BUG. Reported bugs are supposed to get urgent priority...even if Andrew is working on something BIG (and he is...performance improvements in the Multi-Resolution workflow and Subdivision Levels). 

[MagnusL]

Thanks man. I turned it off but, No. it makes no difference.. the skipping is still there.  tried 10 million polys and down to 50.000.. it has to be something else.

Ah. OK, i thought this forum was monitored by the devs occasionally as a secondary platform for solutions.. I'll see if i can whip soething together and send in..
This issue is not so bad compared to other things that is beginning to drive me nuts.

[Carlosan]

Please remember to ask Andrew about this issue at

Andrew Shpagin <andrewshpagin@gmail.com>

[MagnusL]

Thanks Carlosan, the world would probably stop if you stopped being so active here.
I posted the report with detailed information on the 14'th of september to Stanislav @ support..  Mailing directly to the big dog?  If this is the way you do things around here, i'll forward that message again.

 

[Carlosan]

I forwarded Andrew your issue.

If I have any answer, I'll tell you here later.

[MagnusL]

Thanks
just prior i read this post i sent the mail again with the links to videos, so he'll just have an abundance of information to pick from.