******* and all the members who provided feedback:THANK YOU! THANK YOU!This is incredible. I have not had the opportunity to check out the new ideas posted. But I tried a few ideas and FSX now works great!I downloaded 197.13 and using nhancer I set up my usual high setting.BP=O and raised the water settings to one notch bellow the highest, and AG at Dense. That did it!!!!!!!I'm in just complete delight. I did a quick flight from PNW's Seattle to Darrington with massive rain and thunderstorms and the framerates locked at 30 and they stayed around 30. Silky smooth flight.I can't thank everyone here enough. This is what I needed. Now I'm just wondering if it was the driver or the water being raised? If it's the water, How can this be. Higher water means less performance.FSX just gets more and more interesting every year.God bless!

Nice to read that Jose :--))Could you please detail your nHancer settings and copy your FSX.cfg file?Thanks!

This is incredible. I have not had the opportunity to check out the new ideas posted. But I tried a few ideas and FSX now works great!

Glad to hear Jose :)Make sure (as David asked) to share your settings, it is very important we have all the information we can in order to better understand how to help others.If I were to summarize this whole thread in once sentence I would say: 'BP=0 shifts the balance in FSX from a CPU bound application to a GPU bound one' not in terms or 'RAW' rendering speed, but PROCESSING speed (GPU ability to read rendering commands sent by the CPU)This is now more FACT than observation :) if there were a tool to monitor the number of 'D3D' calls sent to the GPU and the GPU ability to 'keep-up' reading them, it would be irrefutable evidence.. but such tool doesen't exists, there is no way to monitor whats inside the command buffer.

Let me ask once again... Is the texture corruption problem with bufferzones=0 primarily a Nvidia problem? Does owning one of the best Nvdia cards solve the problem? ThanksStephen

Glad to hear Jose :)Make sure (as David asked) to share your settings, it is very important we have all the information we can in order to better understand how to help others.If I were to summarize this whole thread in once sentence I would say: 'BP=0 shifts the balance in FSX from a CPU bound application to a GPU bound one' not in terms or 'RAW' rendering speed, but PROCESSING speed (GPU ability to read rendering commands sent by the CPU)This is now more FACT than observation :) if there were a tool to monitor the number of 'D3D' calls sent to the GPU and the GPU ability to 'keep-up' reading them, it would be irrefutable evidence.. but such tool doesen't exists, there is no way to monitor whats inside the command buffer.

Not trying to be argumentative with you, but I completely disagree, the CPU still cant render FSX quick enough to saturate and corrupt most any Decent modern GPU with BP=0 or not, not even close (and that doesn not cause corruption), in the case of FSX, rendering has not shifted enough nor probably ever will to call it GPU bound.Its more like BP=0 results in the CPU not being asked to do what BP is supposed to do, "allocate for one pool of vertex and index buffers to store geometry" and so for the time being it is more "focused on the "raw" rendering, that I would agree with.The fact that we get corruption when turning on more GPU filtering should clue you into this, what is happening is that there is now too much latency between the CPU and GPU, there is no buffer and more GPU filtering requires more passes ahead of time, but since the buffer is gone it cant always keep up, the GPU is starved and thats why we have corruption as we increase filtering, AA aniso., something to that effect, you know what I'm saying, FSX has told the GPU it will be there because "I have a buffer pool" and the GPU says "ok, well I could resally use you right about now BP where are you?"See what this has come down to? The hardware is now talking and animated! There are such tools, Nvperkit and Nvperfhud are great dev tools, as well as some from Intel, problem I think is that you may have to hack for "permissions"

Let me ask once again... Is the texture corruption problem with bufferzones=0 primarily a Nvidia problem? Does owning one of the best Nvdia cards solve the problem? Thanks

Sthephen,Not nVidia's, but more like an architecture limitation, there are different opinions, me, I think it is the Command Buffer being filled causing a CPU/GPU sync problem, which is because of the GPU inability to process commands fast enought, so, *IF* I'm right, then yes a newer card with MORE processing cores will absolutely help..However, shockwave has another opinion, but I have a test that could help you decide...do this:Set Mesh complexity, mesh resolution & Texture Resolution to their LOWEST values, and bring down the water to Middle 2.0.test... YOU WILL CRASH FSX :) why? because you just removed all the options that tax the CPU, letting it now KILL your GPU faster ;) I'm confident the problem is a CPU/GPU sync problem, but.. it is just an opinion Stephen. read Shockwave's too..

the CPU still cant render FSX quick enough to saturate and corrupt most any Decent modern GPU with BP=0 or not, not even close, in the case of FSX, rendering has not shifted enough nor probably ever will to call it GPU bound.

The CPU 'tells' the D3D API what to render via instructions sent to a command 'ring' buffer, which the GPU 'reads' if the GPU can't read the ring buffer fast enought the CPU will OVERWRITE the command buffer with new 'frames' and flushing occurs, thats how D3D works ;) and yes, the CPU WILL send more draw calls to the D3D API than what a GTX 285 is capable of, this is a VERY common problem in gaming consoles, thats why they do SYNC CPU/GPU comunication ;) Having a high PoolSize value is like having a 'bigger' command buffer, at the expense of CPU processing cycles.The GPU processing of the commands in the command buffer is not related to 'RAW' speed of the GPU, but its number of cores, the more cores, the more commands will be read 'at once' from the ring buffer... thats how CPU/GPU comunication works. 'rendering speed' is one thing, and the ability to 'read' a set of data for processing is another... it's like CPU/Memory communication, Imagine a 4.2Ghz CPU running CAS 9 @ 800 vs. CAS 5 Memory speed RAW speed is the same.. but it's ability to read/write pages is improved, so the CPU can do 'more' don't know if it is a good analogy...

Sthephen,Not nVidia's, but more like an architecture limitation, there are different opinions, me, I think it is the Command Buffer being filled causing a CPU/GPU sync problem, which is because of the GPU inability to process commands fast enought, so, *IF* I'm right, then yes a newer card with MORE processing cores will absolutely help..However, shockwave has another opinion, but I have a test that could help you decide...do this:Set Mesh complexity, mesh resolution & Texture Resolution to their LOWEST values, and bring down the water to Middle 2.0.test... YOU WILL CRASH FSX :) why? because you just removed all the options that tax the CPU, letting it now KILL your GPU faster ;) I'm confident the problem is a CPU/GPU sync problem, but.. it is just an opinion Stephen. read Shockwave's too..

I think you would have to turn down AG and water effects as well, water needs multiple passes just on its own and AG is huge.You cant kill a card by loading it, just as you cant kill a CPU by bring it too its knees, you just shift the bottle neck, Yes it is a CPU/Sync problem because the card has been told to render, but it cant.

not only share your settings, but share what addons you run!! try this all in bad real weather with activesky, a complicated addon like pmdg, level-d, etc. scenery like fsaddon airports, ultimate terrain, fsgenesis mesh

Shockwave, I think there is a slight misunderstanding.. the CPU doesn't 'render' anything, it 'tells' the D3D API to do so via a command 'ring' buffer, which the GPU 'reads' if the GPU can't read the ring buffer fast enought the CPU will OVERWRITE the command buffer with new 'frames' and flushing occurs, thats how D3D works ;) and yes, the CPU WILL send more draw calls to the D3D API than what a GTX 285 is capable of, this is a VERY common problem in gaming consoles, thats why they do SYNC CPU/GPU comunication ;)The GPU processing of the commands in the command buffer is not related to 'RAW' speed of the GPU, but its number of cores, the more cores, the more commands will be read 'at once' from the ring buffer... thats like basic D3D stuff, thats how CPU/GPU comunication works.

FSX was coded by Aces as many old game where, to render in software, which means that much of the triangulation and geometry is done on the >CPU not as most games or sims are done today.Please read:"The latest cutting-edge terrain mesh triangulation and LOD computation algorithms are being designed to run in vertex shaders on 3D hardware [9]. However, since Flight Simulator must run on both older and newer hardware, we run our mesh triangulation algorithms in software.......To avoid monopolizing CPU resources, the terrain engine does not refine the entire mesh every frame. Instead, the mesh is refined and triangulated incrementally and the resulting geometry is added to the scene graph when it becomes available using a double buffering scheme.......as the viewpoint moves, an interesting but obviously undesirable outcome. Whenever we update the local origin, all the vertex buffers in every cell of the quad tree must be recomputed relative to the new origin. As this can take several frames, the new vertex data is double buffered and then made active only when all are ready to avoid visible cracks...Due to the complexity of the synthesis algorithm, we execute it in software rather than using video hardware. This of course requires us to use a fast, high-quality 2D software rasterizer."http://msdn.microsoft.com/en-us/esp/cc789357.aspxKind of similar to flash being renderd by CPU rather than GPU

You cant kill a card by loading it, just as you cant kill a CPU by bring it too its knees, you just shift the bottle neck, Yes it is a CPU/Sync problem because the card has been told to render, but it cant.

'kill' was alegoric ;) Completely agree on Adam's paper. in fact.. you are confirming what I just told Sthepen ;) I told him to turn down all CPU bound options (like terrain mesh) which, I know are CPU bound! doesn't make any sense to make a GPU render a mesh system because a CPU is better suited for that task.In any case, I think we both agree that there are CPU/GPU sync issues, I guess we differ on the 'causes' not the actual problem.. but hey, I don't have the source code here.. so this is all opinions :)

'kill' was alegoric ;) Completely agree on Adam's paper. in fact.. you are confirming what I just told Sthepen ;) I told him to turn down all CPU bound options (like terrain mesh) which, I know are CPU bound! doesn't make any sense to make a GPU render a mesh system because a CPU is better suited for that task.In any case, I think we both agree that there are CPU/GPU sync issues, I guess we differ on the 'causes' not the actual problem.. but hey, I don't have the source code here.. so this is all opinions :)

I believe AG are tied to the Mesh LOD.Agree, its a synce issue that the bufferP is meant to prevent, I have enjoyed the discussion, look into to those tools if you really want to peak inside.BTW I never have complemented you on your great flight videos, nice work!

BTW I never have complemented you on your great flight videos, nice work!

Ahhhh.... thanks :) I'm doing another one next sunday for Cross the Pond 2010 (VATSIM) will share

Agree, its a synce issue that the bufferP is meant to prevent

Correct, and that is also the reason it IS there... if you were a MS Lead Developer, with no control whatsoever on CPU/GPU sync issues, what would you do? you allocate system memory as an index buffer in case you run into the problem, its a logic, design consideration, I never said BP was bad :) its just that my hardware is alergic to it ;)

I never said BP was bad :) its just that my hardware is alergic to it ;)

Ha! Oh just go and turn down your sliders!

Hey Guys I need some advice, as you can see from my Sig below I now have BP=0 working perfectly on 2 computers by going back to (a very lean)WinXP, now I am trying to pull of the same feat on my 3rd and final machine.But there's a catch, I use Eyefinity which does not work on Win XP, so I am stuck with Win 7 x64, and I have a 5970 which has 2 GB of ram but split b/w 2 GPUs(1 GB each), and I am seeing some benefit, but not anything like the other machines. I think this is due to the huge Vram requirements of a 5040 x 1050 desktop + FSX using BP=0.Now I am in a quandry I think I should sell my 5970 and get one of the new 5870 with 2gb of ram or possibly get one of the new Fermi cards, the Fermi card would allow me to go back to WinXP which has cleared 95% of all the BP=0 artifacts, but they only come with up to 1.5 GB of RAM.Which do you guys think would be the best option.