Phil's comments are good enough to convince me that SLI is not a total waste since I use high AA settings.

 

Cheers

jja

Damn, and I had a 680GTX in my house the other and the owner even suggested I use it to experiment with it in a SLI configuration, but I passed on the offer. :-/ Could've done some more testing myself, since I do fly with visuals only and instruments on a networked PC.

I apologise for hijacking the thread. BimmerCop, could you please explain how you've networked the instruments as it's something that I have been considering?

 

Regards

Paul

 

Sent from my cm_tenderloin using Tapatalk HD

I apologise for hijacking the thread. BimmerCop, could you please explain how you've networked the instruments as it's something that I have been considering?

 

Regards

Paul

 

Sent from my cm_tenderloin using Tapatalk HD

 

When I was doing the 737NG cockpit, I was using Sim-Avionics. You basically run the gauges off a networked PC and use WideFS (FSUIPC) to have the FS machine send the data to the client machines. As for a Cessna 172 cockpit, I was going to use the freeware gauges from thegaugesfactory.org and the same principle, run them on a networked PC with WideFS.

 

Since I am going to o my cockpit with X-Plane 10 instead, I will be using the GA instrument gauges from FlyElise-NG on a networked PC as well. Instead of WideFS, XP communicates internally with the client. No need for a 3rd party utility such as FSUIPC for that. I will need to use XUIPC however, to have my IOCards communicate with XP.

 

Clear as mud? L'meow!

I never had an SLI setup before but will give you guys the skinny on how 2 MSI 680 GTX Lightning boards pan out when the 2nd comes next week. I'm not hoping for more FPS - just a little extra smoothness. Besides my Corsair 1000 watt PS has been getting lazy lately. Also it is one way to achieve a 4gig GPU solution . Cheers jja

Also it is one way to achieve a 4gig GPU solution . Cheers jja

 

Two 2GB cards in SLI will not yield a 4GB solution. Games will still see 2GB of VRAM. Just FYI...

Here's Phil's post regarding SLI.

 

http://blogs.msdn.co...multi-core.aspx

 

He mentions one or two things that can break SLI in a game. Looks like FSX might be running into one or both of them.

 

As you can see, Phil has never said that FSX can't use SLI. A very common myth. (He also never said that FSX can't use Hyperthreading either). But as FSX is most of the time limited by your CPU's single threaded performance it's only in very specific scenarios were SLI or Hyperthreading (or more than 4 physical cores) are of any use. When you're not at those specific scenarios using either SLI or Hyperthreading has the potential of actually causing reduced performance.

 

This is the nVidia text Phil refers to about what can 'break' SLI in DirectX. I don't really know much about the actual rendering of FSX but do the instruments that 'break' SLI by any chance use render to texture?:

 

 

 

Limit Lag to At Least 2 Frames

DirectX allows drivers to buffer up to three frames. Buffering frames is desirable to ensure that CPU and GPU can work independent of one another and thus achieve maximum performance. On the other hand, the more frames are buffered the longer it takes between issuing a command and seeing its result on-screen. This lag is generally undesirable, since humans can detect and object to lag-times of as little as 30 ms (depending on the test scenario).

Some games thus artificially limit how many frames are buffered. For example, locking the back-buffer forces a hard synchronization between the CPU and the GPU. Locking the back-buffer first stalls the CPU, drains all buffers, and then stalls the GPU. At the end of the lock all systems are idle, and the number of buffered frames is zero.

Stalling a system in this manner has a severe performance penalty and is to be avoided, especially on multi-GPU configurations.

A less objectionable solution to limiting the number of buffered frames is to insert tokens into the command stream (e.g., DirectX event queries) at the end of each frame. Checking that these events have been consumed before issuing additional rendering commands limits the number of buffered frames and thus lag to anywhere between one to three frames.

Multi-GPU systems are particularly sensitive to limiting the number of buffered frames. In general, a system with n GPUs requires at the very least n frames to be buffered to be maximally efficient.

Surprisingly, doing so does not increase lag, since a dual GPU system generally runs twice as fast as a single GPU system. For example, buffering two frames (that take 15 ms each to render) on a dual GPU system has the same 30 ms lag as buffering one frame (that takes 30ms to render) on a single GPU system.

We thus recommend that applications check how many GPUs are available and, if they must, limit the number of buffered frames to at least that number of GPUs. The control panel API (see Section 8.2) allows querying whether a system is in SLI mode and how many GPUs are currently in use. In particular, the function

 

NvCplGetDataInt(NVCPL_API_NUMBER_OF_SLI_GPUS, &number) returns the number of SLI-enabled GPUs in the system. The NVControlPanel_API.pdf document and the NVSDK sample NVCpl provides details.

NVIDIA SLI and Multi-GPU Performance Tips 64

 

8.5.2. 8.5.3.

Update All Render-Target Textures in All Frames that Use Them

The efficiency of a multi-GPU system is inversely proportional to how much data the GPUs share. In the best case, the GPUs share no data, thus have no synchronization overhead, and thus are maximally efficient.

To minimize the amount of shared data, each rendered frame should be independent of all previous frames. In particular, when using render-to-texture techniques, it is desirable that all render-target textures used in a frame are also generated during that same frame. Conversely, avoid updating a render target only every other frame, yet using the same render-target as a texture in every frame.

If an application is explicitly skipping render-target updates to increase rendering speed on single GPU systems, then it might be of advantage to modify that algorithm for multi-GPU configurations. For example, detect if the application is running with multiple GPUs and if so, update render-targets every frame (i.e., to increase visual fidelity) or update render-targets two frames in a row and then skip updates two frames in a row.

Alternatively, rendering to render-targets early on and only using the result late in the frame is also beneficial for SLI systems. It avoids stalling one GPU waiting for the results of the other GPU’s render to texture operation.

 

Clear Color and Z for Render Targets and Frame Buffers

Clearing the color and z information of a render target prior to its use indicates to the driver and the GPU that any existing data in the render target is irrelevant. Conversely, not clearing that data indicates that the data may be relevant and thus needs to be maintained, and in the case of SLI configurations shared between GPUs.

Clearing z is generally advisable even knowing that all z-values in the render target are going to be overwritten later (see Section 3.6.2): clearing z is close to free and enables early z-cull optimizations. On SLI configurations, an added benefit is avoiding synchronizing this z-information across the GPUs.

Similarly, clearing color is advisable on SLI configurations as it avoids synchronization overhead between the GPUs. Thus, you should always clear color, even when knowing that every pixel in the render target is going to be overwritten later anyway.

Strangely, despite what is being said here, I actually *do* get a noticeable boost with SLI on a plane like the NGX. So though I didn't claim that SLI gives a boost universally in *every* circumstance, there are no circumstances that I have personally encountered where I wasn't seeing a benefit, all settings and situations being equal. I'm also running older Nvidia drivers too. In my experience, using drivers past past 2.6something appear to require larger transparency AA to avoid shimmering, and that really degrades my performance, so I've been forced to stick with the older ones until such time as I can upgrade cards.(which sucks for other games/sims like DCS).

Found this is NickN's guide: The only time Vsync OFF may present an advantage is with SLi. Because of how Sli works running with Vsync disabled may help as Phil Taylor pointed out quite clearly in SLi FSX is throttling you with Vsync enabled and frames locked. Cheers jja

Yea it is weird how these tips just pop up out of nowhere. I was doing a search for ForceWindowedvSync and this showed up. Anyway I also will be giving SLI a try for the first time and while my expectations aren't that high it should be fun to see the differences. Cheers

From nVidia:

 

If you see horizontal or vertical green lines on your screen (shown here), it means that you have "Show SLI Visual Indicators" enabled in the NVIDIA Display control panel. When enabled, this option shows how your GPUs are sharing the graphics load and will overlay the name of SLI in your system: 2-way SLI will overlay “SLI”, 3-way NVIDIA SLI will overlay “SLI x3”, and Quad SLI will overlay “Quad SLI”. For games that are rendered using alternate frame rendering (AFR), a green vertical bar will grow up and down on your screen, depending on the amount of scaling. For games that are rendered using split-frame rendering (SFR), a green horizontal line will move up and down on your screen, showing how the load is being balanced between each GPU. If the upper half and the lower half of the screen have a similar level of detail, the horizontal line will stay close to the middle. To enable or disable this feature, simply open the NVIDIA Control Panel and select 3D Settings. With the 3D Settings page open, click on the 3D Settings tab in the upper menu bar (shown here)

 

 

This will indicate if SLi is working in whatever FSX setup you have.

 

For CPU-bound applications, NVIDIA offers a new SLI rendering mode called SLI Antialiasing. This rendering mode allows you to enable SLI8x, SLI16x, or SLI32x (for quad SLI only) antialiasing and enhance the visual quality of any gaming application.

 

There are several factors involved:

 

1. Removing the VC reduces CPU load improving frame rates (you can experience this Multi or single GPU)

2. What mode of SLi is being used

3. Vsynch

4. SLi Focus Display

5. Number of monitors

6. How FSX is calculating fps (see how AFR - alternate frame render can give a false fps value)

7. Micro stuttering (inherent in multi-GPU configurations)

8. PCI 3.0 or 2.0 (16X slots, 8X slots)

 

From my testing in multi-GPU configurations I can't rely on the FSX Ctrl+Z fps displayed in FSX. I've gone back and forth with nVidia SLi, AMD Crossfire, single GPU ... but I always seem to end back at a single GPU in multiple computers.

 

But if your trying to decide on SLi, then I'd say go for it ... there are other games/sims/applications that can use SLi effectively.

Still seems like an advantage to using SLI in FSX. Cheers jja

Anyone that thinks that SLI doesn't help in FSX is just plain nuts. Installed a second MSI 680 GTX Lightening and frames have more than doubled (100+ in heavy clouds). Still testing but so far so good.

 

Cheers

jja

My initial test was in outside view (where I do alot of flying) and you were right that in the RA T-Duke I saw no SLI advantage. This makes sense to me as FSX is too busy munching on gauge and physics code. The best answer is to rewrite the FSX engine to use the GPU cuda cores and Physix API as GPUs are way faster than CPUs these days.

 

Cheers

jja

The best answer is to rewrite the FSX engine to use the GPU cuda cores and Physix API as GPUs are way faster than CPUs these days.

 

Cheers

jja

 

Good luck with that

 

Sent from my Galaxy Nexus using Tapatalk 2