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. It is not an "implication". FSX's graphics engine uses D3D. It is by definition using hardware 3d acceleration. 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.

You seem to just make statements out of the thin air or in your case thick air, I'm not sure. Then you try to cut and paste some definition that comes across like gibberish to hide behind and that no one asked about and with out regard to anything that has been stated. Are you ill? Why don't you stay on track with regard to what has been said. For instance, for the third time what and to who are you replying to in the above with "Pixel shaders ..etc"? I post the freaking specs to both of those cards and you try to start posting crap about what it all means as if someone asked a question about it, which is about -2% relevant to the conversation at hand in which you keep denying what has been fact for years with regard to FS rendering. What planet are you on?Second you fail to take into any account about primitives that can be more GPU-Bound or CPU-bound that a developer would choose and why/what as it relates to when FS code was written. And now you want to try to twist what Phil Taylor said as well as what I have posted.What do you think CPU dependant means? Why do you think SLI profiles have almost no bearing on FSX performance until trying to AA at ultra high res as Phil and other have pointed out? Duh!You sir are acting like the nurse gave you too much of something and if you are suffering from something that

For the rest who still wonder about FSX GPU vs CPU dependancy in this shambled thread lets try to boil it down:Take away any post filtering (Antialiasing and Anisotropic filtering) that simply clear up the jaggys and corrects aliasing effects and thus preserves more detail that would be lost .. and what does the GPU offer FSX?Notice the benchies for some older DX10 cards using different CPUs and clock speeds http://www.tomshardware.com/reviews/cpu-gp...de,1928-10.htmlAlso a good read would be "Maximizing FSX Performance - CPU or GPU?" from Computer Pilot magazine Jan 09.By Doug Horton Draw your own conclusions based on reality.We all look forward to Fermi, and it would be great if Max is right. But as stated I dont think we should expect very much in the form of its new abilities outside of AA, AF and a bit of shader power for bloom and water effects as far as FSX is concerend (32xAA sounds great though!).

"FlyingBits", take a breather from this thread and tone down the unecessary language and personal insults.

"FlyingBits", take a breather from this thread and tone down the unecessary language and personal insults.

Yesir, Oxygen on full...sorry...sorrywalks away in shame......Hey someone has to keep you guys busy and in a job dont they?Sorry...sorry...

Some more info on GF100's triangle setup rate from the Tech Report

Once the polymorph engines have finished their work, the resulting data are forwarded the GF100's four raster engines. Optimally, each one of those engines can process a single triangle per clock cycle. The GF100 can thus claim a peak theoretical throughput rate of four polygons per cycle, although Alben called that "the impossible-to-achieve rate," since other factors will limit throughput in practice. Nvidia tells us that in directed tests, GF100 has averaged as many as 3.2 triangles per clock, which is still quite formidable.

3.2 tri/clk is very impressive, but this is a peak rate only achievable in synthetic tests (i.e. not real games). Realistically we can expect something more like 2 tri/clk, which is still a doubling of the current rate and should provide a nice boost for geometry-limited titles such as FSX.

3.2 tri/clk is very impressive, but this is a peak rate only achievable in synthetic tests (i.e. not real games). Realistically we can expect something more like 2 tri/clk, which is still a doubling of the current rate and should provide a nice boost for geometry-limited titles such as FSX.

Nice :( Very promising!

Some more info on GF100's triangle setup rate from the Tech Report3.2 tri/clk is very impressive, but this is a peak rate only achievable in synthetic tests (i.e. not real games). Realistically we can expect something more like 2 tri/clk, which is still a doubling of the current rate and should provide a nice boost for geometry-limited titles such as FSX.

Except I'll just say, respectfully, When FSX was coded there were I believe Four D3D Primitives to choose from in DX9 that would be used for FSX (primitives=render triangles), two that were CPU-bound and Two that were HW, or GPU bound. FSX was mainly coded as CPU-bound. Hence PT's comments "bound in the D3D runtime and driver on the CPU due to how many Draw and SetTexture calls we issue" He didnt say bound on the GPU because FSX is not coded that way.The rendering Geomitry is done on the CPU in the case of FSX so Firmi will still be waiting for CPU cycles just as all of our GPUs do now, just as the benchies from Toms show and so the point I was trying to make to you is that Fermi cant change that unless FSX is written a new.Apologies to you MAX for my frustration in the seeming lack of abilities to comunicate, I have a real hard time with the English.Edit: Please, anyone from Aces feel free to chime in with additiona or corrections...

I really enjoyed reading this thread guys (TechGuy and FlyingBits)! It makes me thankful that I stayed really, really stupid regarding technical stuff like this and couldn't jump into the fray. :( (I do know how to place the video card on the MB and install the drivers though)! It was definitely interesting (okay, funny) to read the exchanges and I think I learned a lot about the GF100, especially as it relates to FSX. I have been looking at all the pictures on the HardOCP website as reading anything about this hardware would be like learning a foreign language. This thread was what I was really looking for as FSX is about the only game I play and I'm looking to upgrade some day soon. It's great that we have some great technical experts on the AVSIM forums!Best regards,Jim Young

Thank you for your apology. I also apologize if I caused any offense.

Except I'll just say, respectfully, When FSX was coded there were I believe Four D3D Primitives to choose from in DX9 that would be used for FSX (primitives=render triangles), two that were CPU-bound and Two that were HW, or GPU bound. FSX was mainly coded as CPU-bound. Hence PT's comments "bound in the D3D runtime and driver on the CPU due to how many Draw and SetTexture calls we issue" He didnt say bound on the GPU because FSX is not coded that way.

The CPU doesn't actually compute anything WRT geometry, texturing, shading, etc. Calls are generated by FSX.exe and issued through the DirectX API. The GPU driver picks up these calls, and dispatches work to the GPU accordingly. This work is then processed by the GPU and output to your monitor in the form of frames. Again, PT's comments are referring to the usage of CPU cycles by FSX's 3d engine. This does not mean FSX is rendered on your CPU.

The rendering Geomitry is done on the CPU in the case of FSX

This is incorrect, as I have explained above (and previously).

so Firmi will still be waiting for CPU cycles

Until the driver moves over to the GPU, there will always be a CPU bottleneck at varying points during rasterization. This does not mean there is no performance to be gained by increasing GPU performance via increased triangle setup rate.

Thank you for your apology. I also apologize if I caused any offense. The CPU doesn't actually compute anything WRT geometry, texturing, shading, etc. Calls are generated by FSX.exe and issued through the DirectX API. The GPU driver picks up these calls, and dispatches work to the GPU accordingly. This work is then processed by the GPU and output to your monitor in the form of frames. Again, PT's comments are referring to the usage of CPU cycles by FSX's 3d engine. This does not mean FSX is rendered on your CPU. This is incorrect, as I have explained above (and previously). Until the driver moves over to the GPU, there will always be a CPU bottleneck at varying points during rasterization. This does not mean there is no performance to be gained by increasing GPU performance via increased triangle setup rate.

Its all good MAX, cheers!But U R Wrong. :) Stay with me now...Maybe you are reading from a textbook, I dunno, but maybe you should come here and take a refresher 3d course at RIT...(I love you more)Could it be be you are confusing Vertex Shader rendering which FSX uses comparatively very very little of (Bloom, Waves Etc.)? Sure it all passes thru shaders but that is different than calculated vertex, is pixel No? <1.a You seem to deny that for almost for ever Calculation and drawing of vertices/triangles has been done on the CPU, that is a basic fundamental no? 1.b I guess this is more os a question, what do you think is taking place on our 4ghz quads CPUs that they strugle with so much? Calculating audio? Calculating text? Why is it everyone complains about the way the FSX was still CODED? Why does everyone (well almost everyone) including Aces, Anand, The guys at HardOCP and almost everywhere (except this post) say "FSX is a CPU bound game" What must they be talking about? And why are some games not so "CPU-bound"?2. It was not up until DX7 that we had the possibility to put some of this calculation/rendering onto the GPU, it was called T&L for transform & Lighting, which in DX8 evolved into what we can code to use today on the GPU > called Vertex Shaders because they are programmable and can run so called (vertex) shader programs to calculate and even animate the geometry, great. FSX uses more than before but still very little of it, the Waves, Bloom effects and a few others make good use of the shaders ..thats it.3. Programers still have the choice of rendering primitives via CPU (CPU-bound) or if it is to advantage even in efficient batches via the programmable vertex shaders on the GPU (GPU-bound)4. The very first large Photoreal scenery package for FS5.0 in 256 dithered colors was stunning and running in DOS (Malard SanFransisco). How did it get rendered Max? There was no Rendering or calculations being done on any GPU. This is was with DOS6? if I remember right and we used win3.11 It was a Raytraced fully textured mesh and it was coded and rendered all on the >CPU> which is still referred to as Software rendering (only by us old guys I guess right?) as we did not have 3d accelerators on our desktops back then. Edit: I think I ran this on a brand new 486-dx2-66 >66hz!http://www.mobygames.com/game/san-francisc...CoverId,128296/This is what some of that huge code looked like before being compiled in good old SCASM (it has been extremely cut down and it is amaising that I still have it from so many HDs dying):Note: There were no calls to render anywere but on the CPUPerspectiveCall(:L000001)Jump(:L000000):L000001PerspectiveRefPoint( 2 :L000002 1.0119047 43.142805 -77.612396 v1= 8000 v2= 8000 0 E=0.200000);43.152081 -77.600911 was-77.599711 LoadBitmap( 0 L5 E0 0 128 0 san000153.r8 )Points( 00 173 0257 171 0514 173 0771 171 01028 170 01285 169 01542 164 01799 164 02055 164 00 176 257 257 171 257 514 172 257 771 170 257 .....snip.....1028 171 20551285 170 20551542 170 20551799 170 20552055 166 2055) TexPoly( 0 0 -32767 0 0 0 0 9 0 32 10 32 32 ) TexPoly( 0 0 -32767 0 0 0 0 10 32 32 1 32 0 ) ......snip.....TexPoly( 0 0 -32767 070 224 22480 256 25671 256 224):L000002Return:L000000EndAPlease feel free to let me know what else I have wrong...Thanks

I really enjoyed reading this thread guys (TechGuy and FlyingBits)! It makes me thankful that I stayed really, really stupid regarding technical stuff like this and couldn't jump into the fray. :( (I do know how to place the video card on the MB and install the drivers though)! It was definitely interesting (okay, funny) to read the exchanges and I think I learned a lot about the GF100, especially as it relates to FSX. I have been looking at all the pictures on the HardOCP website as reading anything about this hardware would be like learning a foreign language. This thread was what I was really looking for as FSX is about the only game I play and I'm looking to upgrade some day soon. It's great that we have some great technical experts on the AVSIM forums!Best regards,Jim Young

Jim,Your post is just about the only one on this thread that I have any hope of even being able to read without learning new words. Even Pandoran is easier to comprehend because at least you can see the expressions on the blue faces. Without pictures and a private tutor I am just as much or more lost as it seems you are.My answer to the disagreement in question: Whatever...Stephen :(

Jim,Your post is just about the only one on this thread that I have any hope of even being able to read without learning new words. Even Pandoran is easier to comprehend because at least you can see the expressions on the blue faces. Without pictures and a private tutor I am just as much or more lost as it seems you are.My answer to the disagreement in question: Whatever...Stephen :(

Oh come on, Just keep an open bottle of Imperia Vodka near by, it will all start to make sense...Yes, big headache indeed. I try not to understand any of it myself and prefer a dummied down gui to work with!

FS 5.0 has NOTHING to do with FSX.You keep coming back to FSX being CPU-bound, but you seem to not fully understand what this means. CPU-bound means the application depends more on the performance of the CPU than that of the GPU. It does not mean the game is rendered on the CPU.

FS 5.0 has NOTHING to do with FSX.You keep coming back to FSX being CPU-bound, but you seem to not fully understand what this means. CPU-bound means the application depends more on the performance of the CPU than that of the GPU. It does not mean the game is rendered on the CPU.

Really? You make fun of me after all that? Sorry for my bad English but that is funny; a person would have to be very unfamiliar to say FS5 has nothing to do with FSX, that old FS5 sample code I just showed you that I wrote works all the way up to FSX SP1 without even using the SDK!Down, below, you will hear from the main FSX terrain developer, Adam Szofran for you to also deny, but first....I'm not sure you are in any position to tell anyone what they "fully understand" about FSX rendering are you? I mean, lets get down to it; I'm calling you out so we don't keep watering down the Avsim forums with anymore bogus fake talk and wasting bandwidth etc. Everything was just put before you, how vertex rendering started, where we are now and how FSX is coded, even with some sample code, some statements from PT, benchmarks with four different GPUs all delivering the same FPS when filtering is off..(But yet for some strange reason can't improve even 1 FPS though the shaders and rendering is of different powers)I gave you a way out, to reason with, but what you say to me? Huh?You post accusation to me and try to say I didn't know what I was talking about? But yet you cant even answer some simple basic questions and then make the classic Faux pas

FSX is absolutely not a GPU-limited engine. The CPU feeds triangles to the GPU in FSX - tons of older games were this way. Trust me, I've been playing games since before 3D cards existed. This is the very definition of a CPU-limited engine. The CryEngine is an example of an actual GPU-limited engine - the video card you're using makes a gigantic difference in the game's performance. Sub-1FPS slide show to totally smooth depending on the card you have installed, on the exact same system. This very clearly does not happen in FSX - the reason you do see some improvement going from an old card to a new is because PARTS of the engine do use the card - there's some shader stuff that was essentially overlayed onto the old CPU-bound renderer, but the core of the engine is not able to take advantage of all that geometry setup stuff in a modern video card.If you go and read the previews of these GF100 cards on the various hardware tech sites, I think it's pretty clear that this is not the "holy grail" and in fact I'm worried it may actually perform worse than a GTX285 in CPU-bound games. It's going to be the best card ever made in GPU-limited games, but that seems to be what they really designed and targeted it for and the benchmarks show CPU-limited games suffering as a result. Really though, this is exactly what they should be doing - their market is way bigger than a few flight simmers. If this ends up being true, the GTX285 and Radeon 5850/5870 are the cards to have, not this.We'll have to wait until someone can actually benchmark this card in FSX, but I'm very doubtful of the claim that this is going to accelerate FSX in any real way. It's certainly not going to be me playing the guinea pig!