ad_verbum

As you told you are IT experienced then it seems to be hardware (card) related problem or something went wrong with Nvidia driver instalation. If you can replace (borrow) graphics card with different one it should help you a lot with diagnose of the problem.

Have you changed monitor setup from 2D surround mode to normal mode with two monitor configuration BEFORE you unplugged third one (before closing system)? It is important you have proper settings before you shutdown system and run again with two monitors only. What may be helpful - try to run your configuration starting from simplest setup: - connect only one monitor to DVI-I port being sure that 2D surround mode was ealier disabled, you shouldn't have any problem with that if your card is OK. - then if one monitor configuration is working shutdown system and connect second monitor to DVI-D port and run computer. If your card and monitors are OK you will get both monitors working. Then go to Nvidia panel to sections "set multiple displays", "change resolution" to make adjustments if necessary. It must be working or your graphics card is damaged or monitors are incompatible/damaged.

1. Resolution of FSX default mesh: USA - 38m, it is resampled resolution* (source: ?, source resolution: ?) Western Europe, Mexico, Canada - 76m, it is resampled resolution* (source: SRTM, source resolution: 90m) Rest of world - 304m or 608m Very few small areas may have better resolution that mentioned above. There was the list of these places at FS Insider (if I remember correctly), but MS removed it as many other resources of FS Insider after closing ACES Studio. Maybe somebody have it and would like to remaind? 2. Resolution of freeware mesh for FSX (FSX Freeware Global Terrain Mesh Project): USA - FSX resolution 10m (source: NED, source resolution: may vary but mainly 10m) Canada (Quebec) - FSX resolution 38m, it is resampled resolution* (source: SRTM or CDED, source resolution: 20m or 90m) Canada (West) - FSX resolution 19m (source: CDED, source resolution: ~20m or 90m depending source 1:50K CDED or 1:250K CDED) Western Europe - FSX resolution 38m, it is resampled resolution* (source: SRTM, source resolution: 90m) Australia - FSX resolution 76m, it is resampled resolution* (source: SRTM, source resolution: 90m) New Zeland - FSX resolution 76m, it is resampled resolution* (source: SRTM, source resolution: 90m) 3. Resolution of commercial meshes for FSX: FSGenesis: USA - FSX resolution 10m, (source: NED, source resolution: may vary but mainly 10m) Canada - FSX resolution 19m (source: CDED, source resolution: ~20m if 1:50K CDED was used) Western Europe - FSX resolution 10m (source: NEXT Map, source resolution: 5m or better) Northern Andes - FSX resolution 19m, it is resampled resolution* (source: NEXT Map 30, source resolution: 30m, compilation of SRTM 90m and ASTER 30m data) Rest of world - possibly next areas with NEXT Map 30 from FSGenesis. Notice - for now NEXT Map 30 is the best avaliable source with world wide coverage. FS Global Ultimate: The producer do not specify the grid resolution for some of geographical areas. Only given are: USA resolution (10m), part of Canada (19m) and Mexico (38m). We can suppose that if the publisher does not want to brag, the source material for the rest of areas was the SRTM 90m. FranceVFR: Western Europe - FSX resolution 5m (source: NEXT Map, source resolution: 5m or better) Some European sceneries (Playsimspublishing - HorizonVFR, FranceVFR) come with included very high resolution mesh (5m or 10m). * Important notice about resampling: In most cases source resolutions: 90m (SRTM), 30m (ASTER, NEXT Map 30) doesn't match to FSX's mesh LOD steps (19m, 38m, 76m, 152m) and must be resampled to one of two adjacent mesh LOD levels. For example world wide SRTM data with resolution 90m is resampled to 76m mesh, sometimes called 76m SRTM mesh, but that doesn't improve level of detail (terrain relief) - it depends only on source resolution.

You are magician ;-) making terrain improvements without source data. if you are using mesh with 38m resolution that means two closest vertices of terrain with elevation data are spaced from each other by 38m. There isn't any data between these two points. Adding some more points between by making interpolation you should get only straight line with some more points on that line, so what sense is to do that? The same I may say about FSX code. Are you sure that FSX is able to take advantages of hardware tessellation in PolyMorph Engine on Fermi/Kepler GPU? I don't think so as hardware tessellation is avaliable since DirectX 11. It is still a lot of work to be done for CPU in FSX world and if I remember correctly in any demanding conditions (high resolution photosceneries, high res. mesh - some european sceneries comes with 5m meshes that is huge amount of data, large and detalied airports) bottleneck is CPU. So that isn't wise idea wasting computational power of CPU for making "empty" tessellation without proper source data. If you are familiar with FSX SDK you may easy check what is influence of exaggerated mesh resolution setting on CPU workload. Just make some empty (gray) ground fotoscenery tiles covering area about 30 x 30 km and test such scenery with default USA mesh (38m) - notice workload of T&t loaders (core1, core2, core3). Next repeat the same with 38m mesh and lower mesh resolution settings (for example 10m and 2m) - again notice workload of T&t loaders. Then compare results. I did a lot of such tests with default USA mesh and 10m FSGenesis mesh around KBIH airport. Conclusions are simple: (1) default mesh (38m) and mesh resolution settings: 38m - are causing low workload (2) default mesh (38m) and mesh resolution settings: 5m - are causing much higher workload than in case (1), terrain looks exactly the same as in case (1) (3) high res. mesh (10m) and mesh resolution settings: 10m are causing middle workload (4) high res. mesh (10m) and mesh resolution settings: 2m are causing much higher workload than in case (3), terrain looks exactly the same as in case (3) Why fotoscenery? Answer is simple, in such case only data will be mesh and very simple texture (our gray one) - no vector objects, no autogen - just to measure mesh influence on CPU workload. Why gray tiles? Because of very low data level in .bgl files and excelent view of terrain relief.

Don't you understand about what is this info? One meter is just example. It is about unnecessary interpolation and tesselation made when is used lower (closer to 1m) setting than is resolution in source data. In default FSX most of USA has 38m mesh and every lower setting (19, 10, 5, 2, 1) than 38m causes unnecessary workload for both CPU and GPU. Lower the settings (closer to 1m), more unnecesary computational work.

Are you sure? Read what Phil Taylor from ACES Studio wrote: "30m source data and a slider set to 1m is causing a lot of interpolation code to run on the BGL data as well as a tessellation to triangles for the hw rendering." Source: http://blogs.msdn.com/b/ptaylor/archive/2007/10/28/game-engine-design-design-goals-and-design-influences.aspx

For example: since 737 NGX, Lod_radius=6.5, photoscenery with "texture resolution" 1.2m and large airport with "scenery compexity - extremely dense". Are you able to maintain 60FPS (for Vsync) even with [email protected] with such settings? I think you may be happy with 30FPS.

Are you sure that only change was replacing GTX 560Ti with a GTX 670? No others changes in hardware and FSX configuration files? The key for a pleasant flying with FSXem is high image quality (with high definition textures, sharp ground, no stutters) obtained with a satisfactory defined (locked) FPS level (30FPS is preffered as half of Vsync). Maintaining this is far more dependent on the performance of the CPU and the appropriate balance of important parameters in fsx.cfg than using extremly powerfull graphics card. For each configuration of the computer for FSX can be matched appropriately powerful graphics card and its replacement by faster one already do not help - but ALWAYS use a faster CPU will give more FPS. At the same time, it is clear that the three monitor setup requires more efficient card than a single screen configuration. However, there is nothing to believe that in a well-balanced rig replacement GTX560Ti graphics card with the GTX670 will lead to increase FPS of 5 frames over the initial level of ~25 FPS - that would be increase of performance by 20% - really huge and hard to believe - especially without any changes to CPU. Of course, you can configure parameters such way that even the GTX670 will have problems, just exaggerate with texture_max_load and Anti-Aliasing settings, using 4096 and 2x2SS + 8xMS. However, is is hard to say such behavior is optimal. Bluescan, I think you did good choice with GTX660Ti and if you want better performance in future you should more think about faster CPU, maybe about incoming Haswell than about faster GPU. Btw Before buying my GTX660 I was testing both cards GTX660 and GTX670. I didn't see any noticeable difference at any sceneries I'm using, even under heavy weather condition made by REXE+ weather engine.

Where I wrote something about "running at full power"? There is difference between "heavy load on GPU" and "running at full power". It is easy to notice difference using GPU-Z Sensors. You may have high (nearly 100%) GPU Load and much lower (60-70%) Power Consumption. More detailed explanation below. Kepler GPU architecture has some specialized type of units like: Raster Engine, CUDA cores, Texture units, Special Function Units (SFU-s), PolyMorph Engine. There are some important differences in the way how is Kepler architecture built and how is handling data in comparison with Fermi. I even don't mention changes between Tesla, G92, G80. FSX, or precisely Direct3D 9 functions which FSX uses, aren't able to utilize Kepler units in efficient way. Kepler architecture is designed to fully and efficently utilize Direct3D 11 set of instructions. Although there is backward compatibility between D3D11 and D3D9, structural differences are very significant. When card is runing in P0 mode all units all ready to work at full speed (highest level of voltages), FSX calling D3D9 API functions is utilizing only some of these, rest is doing nothing - but all units still are at P0 and producing heat. Of course all units fully loaded (receiving code and lots of data continously) will consuming even more energy. Card power consumption scales on Power States, data load, CUDA codes utilization by shaders code (simple/demanding code) and PolyMorph Engine utilization.

ASUS GTX660Ti is good choice but with GTX660 TI-DC2T version you will most time (while high GPU-load) producing mainly heat. This model is heavy factory OC-ed, +157 MHz above reference level (980MHz). Even in case of heavy load on GPU, FSX isn't able to use all GPU resources but card is be working in highest power mode (P0) and producing a lot of heat - somewhat unnecessarily. More reasonable, for FSX, would be GTX660 TI-DC2O version, also factoty OC-ed, but not as high, +78 MHz above the same reference level.

It is easier to use this app: http://www.coderbag.com/Programming-C/Disable-CPU-Core-Parking-Utility

For most flying conditions this card is much too powerfull for FSX (I mean by that it will be only lightly loaded). Only in very hard weather condition (heavy overcast), made by weather engines of REXE+ or AS2012, you may utilize power of this GPU. But even in such cases GTX660 or GTX660Ti are enough efficient. If you don't plan to use Nvidia 2D surround mode with three monitors, you may buy GTX660 or GTX660Ti. In the case of 660Ti you will have huge performance safety margin. Notice: Don't expect any FPS increase after changing your GTX560Ti even to GTX670. That depends from CPU.

Don't you have two GPUs in your system? I mean your GTX580 and GPU integrated with CPU. Maybe you connected DVI cable to bad connector (integrated GPU instead GTX580). Second idea is you may have damaged cable.

Stock cooler? It seems to be true mistake especially with IB. Don't you want to OC your CPU? That is the best thing which you may do for using it with FSX.

If you ask about sync polarity answer is yes.