ATTENTIONThis FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices. |
flexsim.com |
#1
|
|||
|
|||
SLI and FlexSim
Have you ever tested Nvidia's SLI with FlexSim?
I was with a client yesterday. They bought 2 Alienware PCs with two 970 GTX, but I couldn't see any noticeable increase in FPS when activating the second GPU. Is there something we need to do on the FlexSim side to enable SLI? |
#2
|
||||
|
||||
We haven't tested FlexSim with an Nvidia SLI configuration, but I don't think you need to do anything special to enable it.
Based on how SLI works and how FlexSim's graphics work, I can offer some insight into why you might not be seeing any performance gains: From Nvidia's website about SLI (http://www.geforce.com/hardware/technology/sli/faq#c11): Quote:
FlexSim is more often CPU-bound than GPU-bound. You have to use much more complicated shapes and shaders than our defaults in order to get a modern GPU to become the bottleneck with FlexSim. And the GPU has to be the bottleneck in order for SLI to be helpful. |
The Following 4 Users Say Thank You to Phil BoBo For This Useful Post: | ||
RalfGruber (09-10-2015) |
#3
|
|||
|
|||
Hi Phil, thanks for your explanation.
Let me tell you a little bit more about our testing. Using the FPS tool in FlexSim 7.7.0 Beta 1, and hitting the F8 key to enable Fly Mode and do the fastest rotation possible, we were getting the same low FPS with and without SLI. The model wasn't running (not CPU bounded?) and having that low FPS might be an indication that we were taxing the GPU, right? The screen resolution was full HD at least. |
#4
|
||||
|
||||
Whether the model is running or not is irrelevant to whether the draw pass is CPU-bound or GPU-bound.
The draw pass loops through each object in the model and gets its location (CPU operations). For each object, it renders the object's shape mesh (GPU operation). If you are using shadows, it calculates the view frustum for each cascade split (CPU operation). For each cascade, it renders the scene into a shadow map (GPU operation). If you have a low framerate because you have a bunch of objects, then you are probably CPU-bound. If you have a low framerate because you have a few really complicated 3D shapes and you are using soft shadows with 4 cascade splits, then you are probably GPU-bound. If turning off shaders increases the framerate, then you are probably GPU-bound. If turning off shaders doesn't give much improvement, then the draw pass is probably CPU-bound. Whether the model is running or how you are repainting the screen is irrelevant. The processing required to render each paint message is what is relevant. Rendering a paint requires both CPU and GPU operations. If the CPU operations are taking more time than the GPU operations, then adding more GPU power isn't going to get you an increased framerate. |
#5
|
|||
|
|||
Thanks for the info Phil, now I understand better.
We turned off the shadows and saw a big increase on the frame rate and model response to clicks, so we were GPU-bound. Years ago you wrote a script to create thousands of processors on an empty model in order to verify FPS. Would something like that be the best way to test the FPS performance (on GPU bounded situations) with and without SLI and across several computers, or do you suggest something else? |
#6
|
||||
|
||||
If you are using 7.7 and turning off the shadows increased the performance, then you should be GPU-bound, so using SLI should improve the graphics performance when you are using shadows.
For example, If the FPS is 45 without shadows and 10 with shadows, then when you use SLI with shadows, the frame rate should theoretically be somewhere between 10 and 45. The CPU is using no more than 22.2 ms (1000 ms / 45 frames) per pass. So when you drop to 10 FPS (100 ms per pass) by increasing the graphics settings, the extra 77.8 ms is likely mostly on the GPU. You should theoretically be able to lower that 77.8 ms by adding more graphics processing power (via a better card or another card in an SLI configuration). But adding more graphics power isn't going to improve the 22.2 ms that is spent on the CPU per pass. But again, I've never used an SLI configuration so I don't know exactly what you need to configure in the Nvidia control panel to get it to work with FlexSim. To my knowledge, I don't think there is anything an application developer has to do to support SLI; everything should be handled through the Nvidia driver handling the OpenGL calls made by FlexSim. |
The Following 2 Users Say Thank You to Phil BoBo For This Useful Post: | ||
Jorge Toucet (09-15-2015) |
#8
|
||||
|
||||
I've read up on SLI a bit more from Nvidia using their developer documentation instead of marketing web pages to understand in more detail why it isn't helping as much as one would hope.
Apparently, there is a lot more to it than just enabling it in the Nvidia control panel. There are many different SLI modes, and depending on how the OpenGL calls are handled in the application, the different modes may or may not give improved performance. Here are two documents that describe using SLI with an OpenGL application: http://developer.download.nvidia.com...s_2011_Feb.pdf http://http.download.nvidia.com/deve...OpenGL_SLI.pdf I will investigate further into it with an SLI hardware setup to see if I can figure out how to best optimize FlexSim for using SLI. Based on their developer documentation, I suspect there are FlexSim engine changes that will need to be made in order to best utilize SLI. You may be able to get some improvement by making a custom FlexSim SLI profile, but you will need to tweak around with the various SLI modes following Nvidia's documentation to determine what works best and following their best practices. Once I set up a test and learn more about SLI, I'll explain what I've found and what can be done with the current FlexSim version or what will improve in a future release. |
The Following 3 Users Say Thank You to Phil BoBo For This Useful Post: | ||
syseo (09-14-2015) |
#9
|
||||
|
||||
I hooked up two Nvidia Geforce GTX 980 in SLI mode to investigate more into how SLI works.
The first step is enabling SLI in the NVIDIA Control Panel. You can also turn on an SLI Visual Indicator that shows how SLI is working in the application: As far as I know, Nvidia doesn't have an SLI profile for FlexSim, so you have to add FlexSim manually to Program Settings to customize how it uses SLI. In the Program Settings, you can configure it to use SLI for Antialiasing: In this mode, you can see the Visual Indicator showing that it is using SLI antialiasing: In my tests, I didn't seem to have any performance or quality increase when using SLI for antialiasing vs. just using Nvidia's FXAA without SLI. Instead of SLI antialiasing, you can configure the SLI render mode, which is set to "NVIDIA recommended" by default, which I assume is Single-GPU (No SLI usage): If you pick one of the alternate frame rendering modes, then FlexSim shows the SLI indicator, but you see no green bar indicating that SLI is working: I suspect this is because of how our OpenGL calls are being processed. We will probably need to make modifications to the FlexSim 3D engine to take advantage of SLI for performance gains. I'll need to investigate further to figure out what we need to change to accomplish this for a future FlexSim version. For now, you may be able to get improved quality using SLI for antialiasing but not overall performance. Last edited by Phil BoBo; 09-17-2015 at 09:50 AM. |
The Following 5 Users Say Thank You to Phil BoBo For This Useful Post: | ||
RalfGruber (09-17-2015) |