8 Replies Latest reply on May 30, 2017 10:29 AM by Helge Feddersen

    GPU utilisation different svpj sizes

    Helge Feddersen

      HI All,

      quick summary of the situation:

      Win7, nvidia P4000 (376,84 Driver), 64GB RAM, dual Xenon E5v2 Processors, SWX & Visualize 17 SP2

      I tried various drivers (cant find certified ones). in all cases i monitored the GPU load via GPU-Z 1.20


      Visualize Setup is identical for all the 4 Renders. The render Setting was set to GPU rendering only.

      a) 700MB svpj file, b) 95MB svpj file, c) 55MB svpj file, d) 25MB svpj file

      all files were opened and closed in sequence without changing any settings in the Software.


      It would apear as if the performance of the GPU rendering greatly depends on the svpj file size.

      whilst a) & b) were only rendered on the CPU (allthough GPU only was chosen) c) & d) utilized the GPU.


      keeping an eye on the GPU load during render:

      for c) this was jumping from 80 - 90%

      for d) pretty consistant at about 90%

      smaller files are always at 100% GPU load


      i am wondering if anybody can reproduce or has seen this on Machines that have full certified drivers?

      any suggestion as to which driver to use for the P4000?

      maybe somebody can try this on SP3EV (i need to wait until SP3 is officially released).


      feedback is greatly apreciated




        • Re: GPU utilisation different svpj sizes
          Mark Jackson

          I'm having just about the exact same issue. The larger the svpj file the less GPU my system utilizes even though the render mode is set to GPU.


          My system is not a nice as Helge's. Win7, Quadro K4000, 16GB RAM, Single 4 core i7 processor, Visualize 17 SP2.


          I get just about 0% GPU and 90% CPU utilization with a 320MB svpj file, and 100% GPU utilization with a 35MB file.




          • Re: GPU utilisation different svpj sizes
            Ron Bates

            Hi Helge,


            You're driver is certified.  Graphics Card Drivers | Hardware & System Requirements | SOLIDWORKS  indicates 376.84 as certified for 2017 in win7x64


            Re: use of CPU only when choosing GPU only...  Chances are on the larger project files (your a and b examples), you're running out of GPU memory.  In which case, we silently fall back to CPU so the rendering will complete.  I can't be certain without seeing logs, but that's what it sounds like.  We're working with nVidia on similar cases I've seen to determine if we can (1) not run out of memory if possible, but also (2) allow a means for us (Visualize) to know when iRay runs out of GPU memory so we can inform the user with a meaningful message.  Rather than the silent fallback that occurs now...


            In your c and d cases, i"m not sure why it's not 100%.  It's possible it is a byproduct of the same kind of issue...where the larger project (more geometry, larger/more textures, etc.) demands a certain amount of reserved resources from the GPU so actual processing/compute is dropped down a bit during a render.  I'm spit-balling on this one so will have to raise with nVidia to be certain.

              • Re: GPU utilisation different svpj sizes
                Helge Feddersen

                Thanks Ron,

                at the time of posting the Driver was not yet certified - now it is ;-)


                It is very possible that you are right regarding the GPU RAM. I have seen a Post from Brian Hiller mentioning that about 1 GB of VRAM will give you about 5mio Polygons. I have not had the time to test this limit yet but shall and keep you posted.


                What seems reproducable is as soon as you have your image quality in SWX (Options / Document Settings / Image quality) set in the RED then Visualize seems to have problems. Probably due to the high Poly count. The ASM in question had 4500 Parts. As soon as i moved the quality out of the RED i did not have issues with the GPU not working.


                @Mark, maybe you can try to reduce the image quality in SWX then reimport the into Visualize.

                Let us know if this makes a difference for you




              • Re: GPU utilisation different svpj sizes
                Helge Feddersen

                Here is the test i did today...


                basic info:

                always the same ASM with about 4500 Parts

                only adjustment i made was adjusting the image quality in SWX (the image below is just for reference), the files were then saved via "advanced save" on the SWX Visualize Tab, were then drag&dropped into Visualize and rendered directly with out savinig the file. GPU monitoing via GPU-Z


                1) resolution @ 2,58mm - not in the red but very close - the SWX file was about 38MB, 8.8mio Poly - rendered without any issues

                2) resolution @ 2,5267mm - in the red - the SWX file was about 77MB, 16mio Polys - rendered at about 92% GPU load

                3) resolution @ 2,5116mm - in the red - SWX file 118MB, 25mio Polys - rendereing extremely spiky and at the most 5 - 10% GPU load


                As the P4000 has 8GB of VRAM 25mio Polys should not be an issue.


                One thing is sure, the moment you go into the red the Polys explode. As i dont have a better solution at this point - my workflow includes making sure i double check this slider to be in as low a position as possible.




                  • Re: GPU utilisation different svpj sizes
                    Brian Hillner

                    Hi Helge,


                    Thank you for providing the results from your newest tests.

                    While we are digesting them, could you please help with another test?


                    Please open the SW file directly into Visualize by dragging and dropping the assembly into the Visualize home screen. Then in the import window, please choose 'Appearance' and the part grouping mode. This will merge all the parts that share the same appearance in your SW file into 1 part, which will drastically reduce the part count in Visualize. For example, instead of having 500 separate metal screws, you will only have 1 part containing all 500 screws. This will help improve your Visualize performance.


                      • Re: GPU utilisation different svpj sizes
                        Helge Feddersen

                        Hey Brian,


                        did your test on the Nr3 SWX file with resolution @ 2,5116mm size 118MB, 25mio Polys

                        See the screenshot of GPU-Z below.


                        I did hit a lot more 90s but as you can see also a lot of drops to 0

                        The Computer was still rendering when i made the screenshot




                        here is the screen of test for File Nr2 resolution @ 2,5267mm SWX file 77MB, 16mio Polys - rendered at about 94% GPU load

                        PC had finished the render. basically the big red block at GPU load




                        Interesting to note the difference in Memory used

                    • Re: GPU utilisation different svpj sizes
                      Ron Bates

                      Exactly what's happening in terms of GPU load still needs some investigation.  As noted above though, triangle (polygon) count SKYROCKETS as soon as you get into the red on image quality slider.  And poly count jumping from 8 to 30 million will definitely have a impact on performance no matter what.


                      So - I would ask (in all honesty to those people that do it) what is the reason for setting/moving the image quality slider into the red?

                      There is a warning when you do so, and it was honesty added to SW many years ago for some edge cases.


                      • Do you move it into red b/c you see areas where, at reasonable zoom extents (for cameras/animations you intend to produce) you see noticeable faceting?
                      • Do you move it into the red b/c you can...and feel that the max level will always be somehow better?


                      Nevertheless, we'll keep digging into the GPU dropout...