Hello Guest it is April 19, 2024, 11:13:42 AM

Author Topic: High GPU usage workaround  (Read 6268 times)

0 Members and 1 Guest are viewing this topic.

Offline Mauri

*
  •  328 328
    • View Profile
High GPU usage workaround
« on: January 14, 2017, 06:35:50 PM »
Hi,
For those using large Engraving/Carving files on 2.5D and medium files on 3D 4/5 Axis that are experiencing High Power, GPU% and Temperatures (no matter what type of Graphics or how powerful the PC is), you can stop this and have it use negligible usage by not displaying the Toolpath on the Screen.

On the industrial Screen set it is easy just keep it on the Program panel button (not Toolpath Panel button).

But on the Hobby Screen set you have to go to the "Probing" or "Offsets" tabs on the screen.

Alternately you can Turn Off the Toolpath display in the Edit Screen, click the toolpath panel.

Or another way would be to have an on screen button to turn off the Toolpath display feature.

If you toggle to back to the Toolpath screen just to look at the G-Code progress, it will then go back to high GPU usage just while you look, then just toggle back and it will revert back to low usage.

Hope this helps.

Regards,
Mauri.

Offline dude1

*
  •  1,253 1,253
    • View Profile
Re: High GPU usage workaround
« Reply #1 on: January 14, 2017, 11:11:12 PM »
Last yer some test where done between Nvidia and AMD cards the Nvidia cards where run at near max and the AMD cards where only useing 25%.

The computer with the nvidia cards was way more powerful than the computer with the AMD card, AMD won that hands down

Offline Mauri

*
  •  328 328
    • View Profile
Re: High GPU usage workaround
« Reply #2 on: January 15, 2017, 02:37:26 PM »
Dude1,
Thanks for you info, however I tested many NVIDIA, AMD and INTEL and on my medium 4 Axis files size files ALL went to 100% as well as on large 2.5D files.
Yes NVIDIA on my smaller files will use more GPU than the other two.
You can have the fastest PC and Video card in the world and it will still go to 100% usage.
Regards,
Mauri.

Offline dude1

*
  •  1,253 1,253
    • View Profile
Re: High GPU usage workaround
« Reply #3 on: January 15, 2017, 02:48:00 PM »
Can you post the file

Offline Mauri

*
  •  328 328
    • View Profile
Re: High GPU usage workaround
« Reply #4 on: January 15, 2017, 05:35:48 PM »
Dude1,
The file is too large for this site.
I have sent these files to Mach4 Programmers last year and they are aware of the issue, however they have not provided a solution.

You can contact me via email as long as you email provider allows files of over 16MB.

For those who do not understand this high graphics usage issue.
If you have medium to large files for 2.5D and 3D G-Codes the problem is not running/processing the Mach4 G-code, it is purely just displaying the pictorial representation of the G-Code in the Toolpath Display.
The reason for this must be that it is in a continual redraw loop on any Toolpath screen.
Most other OpenGL programs do not do this, only when you move the object do they redraw.
It does not matter if they are 32bit or 64bit programs.
For example Rhino5 is a 32bit (one Processor) and using OpenGL, however it can quite easily move a 1.5GB triangulated shaded files without heavy usage of GPU and it only redraws when you move it.
I am not aware of any program that continually redraws a stationary object on the screen.
The best way to do this is when you move/rotate the Toolpath then and only then should it be redrawn.
Another way would be is to be able to turn the looping redraw off.

Regards,
Mauri.

Offline smurph

*
  • *
  •  1,546 1,546
  • "That there... that's an RV."
    • View Profile
Re: High GPU usage workaround
« Reply #5 on: January 18, 2017, 04:34:24 PM »
The GUI will not redraw on every refresh if you tick the "Use Lazy Tool Path Update?" checkbox in the Mach config Tool Path tab.  Only if the tool path is moved or when G code is running.  If that option is chosen and there is no movement, the OpenGL routines are never called.  I can say this with %100 confidence as I just looked at the code and tested it to be sure.  If you have that checkbox ticked and you still have high GPU usage, then your problem must lie elsewhere.  :(

Here is my GPU graph with a 100MB 3D file loaded.  The red line is the activity line.  The spikes are when I was track balling the tool path around.  The yellow line is the GPU speed, which spikes when zooming the tool path in and out.  Dual AMD R7 370s but Mach never even blips them enough to even dent one card while moving the tool path aggressively. 


Offline Mauri

*
  •  328 328
    • View Profile
Re: High GPU usage workaround
« Reply #6 on: January 19, 2017, 02:25:07 PM »
smurph,
This only applies when you are not running the G-Code.
So if you load the file and view the toolpath display what you say is correct, but when you "Enable" and then "Cycle Start" it will go back to high GPU usage.
So what we need is another option on Toolpath display to only redo display when Toolpath is moved.
I tried 2.5D 3 Axis and 3D 4 Axis with the same result.
Regards,
Mauri.

Offline Mauri

*
  •  328 328
    • View Profile
Re: High GPU usage workaround
« Reply #7 on: January 19, 2017, 02:46:11 PM »
Smurph,
What I have also found is that if you at running "Cycle Start" the G-code at Full Toolpath display, that is when the GPU is at its highest usage, as you Zoom in more and more on the Toolpath display then the GPU usage decreases.
Regards,
Mauri.

Offline smurph

*
  • *
  •  1,546 1,546
  • "That there... that's an RV."
    • View Profile
Re: High GPU usage workaround
« Reply #8 on: January 19, 2017, 04:28:15 PM »
We update the tool path with the cut path.  So while it is not moving, per say, it HAS to be updated when running G code.  I just loaded that 100MB file and looked at my GPU when it is running.  The GPU does go up to about 25% (on one card only) with the tool path zoomed out.  Zoomed in, 5% or less. 

There are two options on how the tool path is run.  Vertex Buffer Objects (aka VBOs, and requires OpenGL version >= 1.5) and the old Mach 3 way.  We test for the v1.5 and if the driver supports it, we use VBOs.  Typically, using VBOs puts more of the work on the GPU and less on the CPU.  But usually, it also lends to smoother video as most graphics cards have faster memory that the RAM that the CPU uses.  But...  all graphics cards and their associated drivers are not created equally.  Just because a drive reports that it can do OpenGL v1.5 doesn't mean it does it well.  Some graphics cards may not even implement it in hardware but choose to emulate it in the driver software.  We can't know this.  All we can know is what the driver tells us.  But finding out that some drivers just plain suck, we offered the option to disable the use of VBOs in the Mach config.  This drops back to the old Mach 3 tool path code.  The Mach 3 tool path style should use more CPU and less GPU.  And it might now move around as slickly.  I used to be able to tell the difference between the two methods, but with my current PC (4GHz 8 core), they feel about the same now. 

BTW, as I was typing this, I loaded the 100MB file on my D2700MUD Atom board that uses an on-board cheap ass Intel GMA.  It took like 15 minutes to load!!!  (Atoms are so slow!)  I have no way of looking at the GPU usage on it, but it does handle that file!  I really didn't think it would.  It seems to track ball around well.

Attached is the GPU graph while RUNNING the file with the tool path fully visible (zoomed out).  The red peaks are ~25%. 

Anyway, the only thing I can say is that you must have a driver or hardware issue that is causing the high GPU usage.  What we do is relatively simple in comparison to something like a video game or even a 3D CAD program.  My AutoDesk Inventor works my GPU much harder than the Mach 4 tool path does.  All we have is a matrix of points that are connected by lines.  This matrix gets dumped into video card memory (if using VBOs) or the computer RAM if not using VBOs.  Nothing special.  Once the matrix is loaded, we really don't do anything more with it except change bits and pieces of it "in memory".  The rotation is handled purely by the OpenGL driver and video card.  When more of the matrix is displayed in the view port, the more processing will be required.  So seeing the GPU usage go up seems perfectly logical. 

So what is causing the high GPU reading?  Is it a driver or hardware issue (most likely) or maybe bad feedback to your GPU monitoring utility?  That's about where we are at this point.  Because if my Atom didn't choke on that 100MB file, I would expect most anything would run well if all was in working order. 

Steve

Offline Mauri

*
  •  328 328
    • View Profile
Re: High GPU usage workaround
« Reply #9 on: January 19, 2017, 08:54:16 PM »
Steve,
Thanks for your efforts.
My test with AMD Radeon HD 8490 using a 3 Axis G-Code file with 2,900,043 lines runs the GPU to 44% and Temp going from 45 to 52 Dec C.
The same file on GTX 970, GTX 640 and a Notebook NVidia all  shows 100% GPU usage.
All have the very latest drivers with OpenGL at 4 plus, so naturally then have to go backwards to use the old 1.5 OpenGL.
Previous test also showed that just using Intel Graphics via their CPU was also similar to the AMD in GPU usage.
Also included is a test with 4 Axis simultaneous with 469867 lines of G-Code pic below with the AMD card.

My question is can I toggle from one Screen that has Toolpath display and then one that does not while the machine is cutting?

Even though with the AMD card the Core GPU clock is intermittently utilized with no toolpath display, the GPU Percentage goes up and down and the Temperature is reduced, it will still be better than showing it all the time and having all these consistently higher.

Will I lose Steps?

Regards,
Mauri.