And the reason is: triangle setup rateGF100 is the only (consumer) GPU on the planet that can setup more than 1 triangle every clock cycle. In fact, it can do (up to) 4 of them each clock cycle. As many of you know by now, MSFS has a lot of geometry in each scene, so much so in fact that it is the primary limiter of GPU performance. This problem could have been solved earlier if MSFS were compatible with the popular multi-GPU rendering mode of AFR (Alternate Frame Rendering), but alas it is not. Note: I have no empirical data which demonstrates that GF100 boosts MSFS performance, this is a *theory* based purely on the recently released GF100 architectural information. If you are interested in learning more about GF100, visit NV's GF100 pageAt the bottom of this page is a link to the Graphics Architecture White Paper, which describes the architecture of GF100 in detail. Note this is *highly* technical in nature.

And the reason is: triangle setup rateGF100 is the only (consumer) GPU on the planet that can setup more than 1 triangle every clock cycle. In fact, it can do (up to) 4 of them each clock cycle. As many of you know by now, MSFS has a lot of geometry in each scene, so much so in fact that it is the primary limiter of GPU performance. This problem could have been solved earlier if MSFS were compatible with the popular multi-GPU rendering mode of AFR (Alternate Frame Rendering), but alas it is not. Note: I have no empirical data which demonstrates that GF100 boosts MSFS performance, this is a *theory* based purely on the recently released GF100 architectural information. If you are interested in learning more about GF100, visit NV's GF100 pageAt the bottom of this page is a link to the Graphics Architecture White Paper, which describes the architecture of GF100 in detail. Note this is *highly* technical in nature.

We would need FSX to be re-written to take advantage of it as FSX uses software rasterizing which is very CPU bound/dependant on the CPU as you know so we can

We would need FSX to be re-written to take advantage of it

False, which is why I made my post in the first place.

as FSX uses software rasterizing

Simply untrue. Triangle setup occurs in hardware, and has in every dedicated graphics accelerator since the Voodoo 1. If it were true, you wouldn't need a graphics card at all. IGPs would be sufficient, and they very clearly are not. Even low-end and mid-range graphics cards are not enough for FSX. Look at all the forum posts here complaining about low FPS/asking for upgrade options with IGPs and low-end/older cards like Geforce 7300/7600/8400/8600/9400/9500. In addition to that, if there were no hardware acceleration occurring, you wouldn't see tons of "which driver is best/this driver doesn't work" posts, which we most certainly do.

False, which is why I made my post in the first place. Simply untrue. Triangle setup occurs in hardware, and has in every dedicated graphics accelerator since the Voodoo 1. If it were true, you wouldn't need a graphics card at all. IGPs would be sufficient, and they very clearly are not. Even low-end and mid-range graphics cards are not enough for FSX. Look at all the forum posts here complaining about low FPS/asking for upgrade options with IGPs and low-end/older cards like Geforce 7300/7600/8400/8600/9400/9500. In addition to that, if there were no hardware acceleration occurring, you wouldn't see tons of "which driver is best/this driver doesn't work" posts, which we most certainly do.

That you come out so strongly opinionated I am really surprised at your limited understanding of FSX as well as 3D gaming in general.You are very confused my friend.What you seem to be stating is that simply if the hardware can do it FS will fall in line and that is what is not true, not with any 3d application.A game written to take advantage of older direct draw API such as FSX (Sure FSX is a DX9 coded, but not even fully), can not take advantage of hardware that needs DX11.FS is coded to do software rasterizing, meaning it will not take advantage of Hardware rasterizing done on the GPU. That is a period. You may want to join a FSX developer forum and find out what you are talking about before posting corrections in which you know nothing.Post processed code from FSX is filtered on the GPU, AA and Aniso, turn that completely off and it almost won't matter at all as to what GPU you have as it will be almost completely insignificant for FSX. As I already mentioned there is some shadder support for things like bloom, but it is weak and mostly only available to the DX10 preview. So then all you have is clock rate and the ROPs to push the pixels to your screen.I will not waste this forums space or my time arguing with you, You would do well to do some research before you reply.I I have been modeling 3D for FS since FS4 as well as participated and contributed in hardware beta programs from both ATI as well as Nvidia starting back when the vesa local bus carried the data and we could start to use 3D APIs in win95 with games so I can speak a bit on the subject and I whish more than anything that FSX could take advantage of newer code, but it cant and it wont. FSX IS mainly A CPU dependant application that can not and will not even take full advantage of all the DX9 code features let alone any newer draw commands beyond some shader commands in DX10> . < That FSX has many textures and poly edges edges that need to get filtered - antialiased, that includes the thousands of alpha textures such as fence and

Wow, I can hardly wait the

Paul,Could you explain why I benchmarked a 25% increase of average fps in FSX when I replaced a 8800GTX card with a GTX285 card? Could it be that the new card managed to process the graphics much faster than the old one?In a couple of months we will know if you or Max was right.

You make a statement "FSX is rasterized in software" and then "prove" this statement by repeating it. I have used reason and real world examples to illustrate why this is not true. Your response is full of hyperbole and "my **** is bigger than yours" comments. Please. The most common D3D call made by FSX.exe is DrawPrimitive - which is the syntax used to create a polygon. You can verify this for yourself by using MS's own D3D performance analysis tool, Pix. I suggest *you* do *your* research before responding.

Wow, I can hardly wait the "Holy Grail" for MSFS?That's kind of like saying an upcoming tire from Michelin or Bridgestone will be the "Holy Grail" for a 1958 Ford Edsel.How would any upcoming GPU be the Holy Grail for a game with a flawed/outdated graphic engine?

If you want to know, I've already explained why in my first post. If you don't understand, you will need to do some research on rasterization as I'm not going to take the time to explain this to you, given your post history.

Paul,Could you explain why I benchmarked a 25% increase of average fps in FSX when I replaced a 8800GTX card with a GTX285 card? Could it be that the new card managed to process the graphics much faster than the old one?In a couple of months we will know if you or Max was right.

IF you have any AA or AF on, and who doesn

The number of shader processors does not determine the number of pixels rendered per clock, that is determined by the ROPs, and the type of pixels (Z or color/MSAA) being drawn. In Nvidia G80/GT200 architecture chips, the number of ROPs is tied into the number of 64-bit memory channels (1 quad-ROP partition per 64-bit memory channel). G80 has up to 6x 64-bit memory channels, and 6 ROP partitions, thus 24 ROPs. GT 200 has up to 8x 64-bit memory channels, and 8 ROP partitions, thus 32 ROPs. Each ROP can output 4 MSAA + 4 Z pixels per clock cycle, or up to 8 Z-only pixels per clock cycle. GT200 in GTX 285 form can output 128 color/MSAA pixels + 128 Z pixels per clock cycle, or 256 Z-only pixels per clock cycle. Look, it is clear you do not understand modern 3d graphics, nor GPU architecture. That's fine and all, as most people don't. But to claim otherwise is to misrepresent one's self.

You make a statement "FSX is rasterized in software" and then "prove" this statement by repeating it. I have used reason and real world examples to illustrate why this is not true. Your response is full of hyperbole and "my **** is bigger than yours" comments. Please. The most common D3D call made by FSX.exe is DrawPrimitive - which is the syntax used to create a polygon. You can verify this for yourself by using MS's own D3D performance analysis tool, Pix. I suggest *you* do *your* research before responding.If you want to know, I've already explained why in my first post. If you don't understand, you will need to do some research on rasterization as I'm not going to take the time to explain this to you, given your post history.

Some instancing methods are GPU bound and some are CPU bound (FSX) so explain why that would be relative? Further please explain to the community why we benefited so much with our new DX10 hardware in FSX? cough....

The number of shader processors does not determine the number of pixels rendered per clock, that is determined by the ROPs, and the type of pixels (Z or color/MSAA) being drawn. In Nvidia G80/GT200 architecture chips, the number of ROPs is tied into the number of 64-bit memory channels (1 quad-ROP partition per 64-bit memory channel). G80 has up to 6x 64-bit memory channels, and 6 ROP partitions, thus 24 ROPs. GT 200 has up to 8x 64-bit memory channels, and 8 ROP partitions, thus 32 ROPs. Each ROP can output 4 MSAA + 4 Z pixels per clock cycle, or up to 8 Z-only pixels per clock cycle. GT200 in GTX 285 form can output 128 color/MSAA pixels + 128 Z pixels per clock cycle, or 256 Z-only pixels per clock cycle. Look, it is clear you do not understand modern 3d graphics, nor GPU architecture. That's fine and all, as most people don't. But to claim otherwise is to misrepresent one's self.

Wow, did you cut and paste that all by yourself? Very nice!Where did I state anything about "The number of shader processors does not determine the number of pixels rendered per clock"?Now please do your best to post something relevant to what was asked....

You don't even know how to derive maximum pixel output for any given GPU architecture and act like I'm the one that doesn't know what I'm talking about. Right. Feel free to stop trolling any time.

You don't even know how to derive maximum pixel output for any given GPU architecture and act like I'm the one that doesn't know what I'm talking about. Right. Feel free to stop trolling any time.

It is sad that you can't formulate a real relevant reply, I thought you posted a good topic but you seem to get really offended when offered some good accurate information.The figures I posted are from NV hardware specs and are correct, so what exactly is your point?Since you seem bent on misleading junior members of our forum with misstatements about FSX I was trying to make a corrrection that was objective and without any bad intention toward you. I gave you my name (its not very impressive I know) so that you could see who I was and that I wasn't some noob hiding behind a screen and that I did in fact have some FS design backround that might be relavant and that was all. <Personal attack removed by mod>Phil Taylor from Aces on a discussion about SLI and Multi Cores ( http://forums.nvidia.com/lofiversion/index.php?t39088.html ):"The issue is that FSX is still CPU bound, and thus the 2nd graphics card only helps when resolutions are above 16x12 with 8x or 16xAA enabled so that the fillrate requirements start to dominate the CPU-boundness. http://blogs.msdn.com/ptaylor/archive/2007...multi-core.aspx is informative. We hope to reduce the sheer number of Draw and SetTexture calls FSX issues even more in SP2(DX10) but that remains to be seen"Hmm, gee.... Beaver, I guess he means the only real impact on a second card would have would be filtering cause thats about all that is getting done...right Mr. Cleaver?"The main issue with FSX is its bound in the D3D runtime and driver on the CPU due to how many Draw and SetTexture calls we issue. It isnt a matter of too much geometry. SP1 reduced the number of API calls issued by 30% or so, as I mention in the perf link. SP2(DX10) will also aim to reduce the API calls another 15-20%. That should help reduce how bound on the CPU side we are and improve overall performance."Gee Wizz shucks...Is that a GPU-bound rendering or CPU-bound rendering instance that Phil refers to? Since there were about only four different ones written for primatives when FSX was coded, what is your point about "DrawPrimitive"s again?So the original reply I gave you is wrong again how? What?

Your "figures" are a mis-interpretation of hardware specifications. Pixel shaders do not output pixels, ROPs do. If you understood 3d hardware you would already know this. I never said FSX wasn't primarily CPU-bound, but thanks for creating a straw man argument to make it look like you're "right" and I'm "wrong". Read the thread title. I said GF100 is the answer for maximizing GPU performance in FSX. If you want the fastest GPU for FSX, GF100 is it. I never made any specific claims as to GF100's effect on FSX. As to PT's comments, CPU time being primarily used by the driver varies between IHVs such that this statement is meaningless out of context. If you don't specify the hardware, driver revision, and O.S. that statement means nothing. As for why this is so, I'd say FSX is one of the most poorly optimized 3d applications of our time. One heavyweight thread for a simulator? Give me a break! No multi-GPU support? Ha! A 3d engine that makes near zero use of modern shaders? What year is this?

Your "figures" are a mis-interpretation of hardware specifications. Pixel shaders do not output pixels, ROPs do. If you understood 3d hardware you would already know this. I never said FSX wasn't primarily CPU-bound, but thanks for creating a straw man argument to make it look like you're "right" and I'm "wrong". Read the thread title. I said GF100 is the answer for maximizing GPU performance in FSX. If you want the fastest GPU for FSX, GF100 is it. I never made any specific claims as to GF100's effect on FSX. As to PT's comments, CPU time being primarily used by the driver varies between IHVs such that this statement is meaningless out of context. If you don't specify the hardware, driver revision, and O.S. that statement means nothing. As for why this is so, I'd say FSX is one of the most poorly optimized 3d applications of our time. One heavyweight thread for a simulator? Give me a break! No multi-GPU support? Ha! A 3d engine that makes near zero use of modern shaders? What year is this?

My "Figures"? Those are NV specs of the 8800GTX and 285GTX <vile language removed by mod>Your "correction" of my reply to you is the bases for this and your implication that FSX rendering is based on the GPU and your "Holy Grail" statement, what are you trying to say now? Phi'ls statements show that very little is done on the GPU with regard to FSX rendering just as I stated. The reason he says that SLI will improve only on High AA and high resolution is exactly what I described about the filtering benefits that the GPU Does bring to the table.I have been on this forum since it came online more than twelve years ago I have no need to troll.I love you man!

My "Figures"? Those are NV specs of the 8800GTX and 285GTX, are you on crack?

Let me explain it again."Pixel shaders" (i.e. ALUs) DON'T OUTPUT PIXELS. ALUs perform mathematical operations upon pixels to modify them. These results are then sent back to the ROPs for blending, MSAA, and output. The fact that I'm having to explain this to you further illustrates my point that you don't understand 3d graphics and as such are in no position to be having a technical debate with me.

Your "correction" of my reply to you is the bases for this and your implication that FSX rendering is based on the GPU and your "Holy Grail" statement, what are you trying to say now?

It is not an "implication". FSX's graphics engine uses D3D. It is by definition using hardware 3d acceleration.

Phi'ls statements show that very little is done on the GPU with regard to FSX rendering just as I stated. The reason he says that SLI will improve only on High AA and high resolution is exactly what I described about the filtering benefits that the GPU Does bring to the table.

PT is discussing how CPU time is used by FSX.exe. That's it. This doesn't mean the application runs entirely on the CPU, it does not mean the CPU is the only limiting factor in performance (i.e. framerate). The application and graphics driver are of course run on the CPU, but the driver issues commands to the GPU which the GPU then processes and outputs to the monitor. Frames have to be rendered and then output by the graphics card. To say this is "software rendering" (as you continue to do) is ludicrous and demonstrates a complete lack of understanding of the rasterization process.