Hello!Due to the discussion of this topic here I have started this topic so any and all interested can join in a discussion reviewing Phil Taylor's "Back of the Envelope" calculations, specifically whether a theoretical calculation alsone is sufficient to prove that autogen BW requirements can exceed PCIe BW, or do we also need a real life-test.My POV is that theoretical upper limits on performance stand by themselves without needing benchmarking proof, but that a benckmark can be useful to measure the actual performance that will be, necessarily, below the theoretical limit.By analogy, if we know the data density on the platters of a HDD and the rotational speed of that HDD, we can calculate a theoretical maximum bandwidth for the HDD without the need of a benchmarking test. Of course if we want to know the actual BW of the HDD, we need to run the test, but we know a priori that whatever BW we are able to measure will be below the theoretical BW. In the same manner, if PT provides theoretical proof that FSX autogen exceeds maximum PCIe 2.0 BW, we can still run tests but we know a priori that autogen on its own can throttle FPS.Of course, PTs calculations in and of themselves could be wrong, so feel free to post any corrections here.Make sure you participate in the poll!Cheers,jahman.

This is the point where I wish I was an admin.Please just drop the topic. You've made your point loud and clear on somebody elses thread. To be completely honest, I couldn't care less about this topic, and I'm sure many more agree. This is one of those topics where every has a different opinion, and you're never going to get a final ruling. We all think what we want to think.

Chris,I think you misread this post: This is a different thread altogether. Thanks for your understanding.Cheers,- jahman.

No it isn't. You have just moved from the other thread, and started a new one, hoping to draw TechGuy into another argument, and showing yourself up in front of the entire Avsim community.Same argument, different location. Just take the advice and drop it. You have your beliefs on this topic, so does Tech guy. You're not likely to change that.

Hello!Due to the discussion of this topic here I have started this topic so any and all interested can join in a discussion reviewing Phil Taylor's "Back of the Envelope" calculations, specifically whether a theoretical calculation alsone is sufficient to prove that autogen BW requirements can exceed PCIe BW, or do we also need a real life-test.My POV is that theoretical upper limits on performance stand by themselves without needing benchmarking proof, but that a benckmark can be useful to measure the actual performance that will be, necessarily, below the theoretical limit.By analogy, if we know the data density on the platters of a HDD and the rotational speed of that HDD, we can calculate a theoretical maximum bandwidth for the HDD without the need of a benchmarking test. Of course if we want to know the actual BW of the HDD, we need to run the test, but we know a priori that whatever BW we are able to measure will be below the theoretical BW. In the same manner, if PT provides theoretical proof that FSX autogen exceeds maximum PCIe 2.0 BW, we can still run tests but we know a priori that autogen on its own can throttle FPS.Of course, PTs calculations in and of themselves could be wrong, so feel free to post any corrections here.Make sure you participate in the poll!Cheers,jahman.

Your argument (and Phil's) relies upon the (unstated) theory that all vertex data for autogen objects is transferred over PCI-e for every frame. If that is true, FSX has the worst 3d engine in history. Have these people not heard of VRAM?

Your argument (and Phil's) relies upon the (unstated) theory that all vertex data for autogen objects is transferred over PCI-e for every frame. If that is true, FSX has the worst 3d engine in history. Have these people not heard of VRAM?

Hi TechguyMaxC, thanks for showing in this thread. I am not aware of the impact of VRAM on PTs calculations (as I said on a previous post, I am a total noob regrding video rendering software - please take this literally :-) Can you expand on this? This is the kind of info we need to polish thoughts and concepts about what FSX can and can't do.Thanks!Cheers,- jahman.

If you absolutely must discuss this, please keep it semi formal, and try not to rip each others heads off. Let's be civilised men. If you don't, I'll have to get an admin in, possibly leading to you guys being banned. And nobody wants that.

Hi TechguyMaxC, thanks for showing in this thread. I am not aware of the impact of VRAM on PTs calculations (as I said on a previous post, I am a total noob regrding video rendering software - please take this literally :-) Can you expand on this? This is the kind of info we need to polish thoughts and concepts about what FSX can and can't do.Thanks!Cheers,- jahman.

Modern 3d engines fetch vertex (and other) data into VRAM not a per-frame basis but rather in batches. Just as data is stored in system RAM after being fetched from the hard drive. If your entire working data set for a scene fits within VRAM, it only makes sense to fetch this data at the beginning of the work process rather than on an ongoing basis, constantly saturating the PCI-e link. In FSX's case since the scene is constantly changing, as new tiles need to be loaded more data needs to be sent over the PCI-e bus. The worst-case scenario described by Phil Taylor either:1) Only occurs before the first frame is ever rendered and as such is not truly a performance limiter2) Occurs every frame and is the worst design possible for a 3d engine. It's like not using system RAM to store your application data but instead streaming everything from the hard drive or optical drive. Chris: thanks for your concern, but as you can see from this thread, it is not needed. Perhaps you are confusing jahman with a certain other member from the thread which preceded this one.

If you don't, I'll have to get an admin in, possibly leading to you guys being banned.

Gotta love a self-appointed traffic cop, going full throttle directing traffic when there is no car in sight.

If you absolutely must discuss this, please keep it semi formal, and try not to rip each others heads off. Let's be civilised men. If you don't, I'll have to get an admin in, possibly leading to you guys being banned. And nobody wants that.

Chris - with all due respect - IMHO - you're out of line - I find the discussion interesting when they are not trying to "one-up" each other so I would like it to continue. The only negative (ish) posts in here are yours. Neither Jahman nor TechguyMax have said anything in here to warrant your reaction.I guarantee the mods have been watching - it's been testy but not a big deal yet.So I suggest you lighten up, cut them some slack and if you don't want to follow the thread - read something else!Vic

Modern 3d engines fetch vertex (and other) data into VRAM not a per-frame basis but rather in batches. Just as data is stored in system RAM after being fetched from the hard drive. If your entire working data set for a scene fits within VRAM, it only makes sense to fetch this data at the beginning of the work process rather than on an ongoing basis, constantly saturating the PCI-e link. In FSX's case since the scene is constantly changing, as new tiles need to be loaded more data needs to be sent over the PCI-e bus. The worst-case scenario described by Phil Taylor either:1) Only occurs before the first frame is ever rendered and as such is not truly a performance limiter2) Occurs every frame and is the worst design possible for a 3d engine. It's like not using system RAM to store your application data but instead streaming everything from the hard drive or optical drive....

Could it be that FSX isn't a "modern 3D engine"? I wouldn't be surprised. I understand batching, but what I read from PT's post is that the additional scenery objects (autogen) you mention that need to be rendered as scenery elements change due to the speed of forward flight are exceeding available PCIe 2.0 BW. At least that seems to be the gist of PT's post (and I presume he is aware of batching and has included its effectsa in his calculations.)Cheers,- jahman.

Could it be that FSX isn't a "modern 3D engine"? I wouldn't be surprised. I understand batching, but what I read from PT's post is that the additional scenery objects (autogen) you mention that need to be rendered as scenery elements change due to the speed of forward flight are exceeding available PCIe 2.0 BW. At least that seems to be the gist of PT's post (and I presume he is aware of batching and has included its effectsa in his calculations.)Cheers,- jahman.

I'm certain FSX is not a modern 3d engine, which is absurd since the modern 3d era started with DirectX 8 which was released in 2001. If just the autogen batch PCI-e traffic exceeds the limits of the PCI-e interface then we will never see FSX run smoothly with autogen maxed because PCI-e will never be fast enough to get around such poor engine design. I can only hope Flight will address this issue.

Not even with PCIe 3.0 BW = 2x PCIe 2.0 BW? 2x seems like a big jump...Cheers,- jahman.

Not even with PCIe 3.0 BW = 2x PCIe 2.0 BW? 2x seems like a big jump...Cheers,- jahman.

It would be interesting to test FSX performance with various autogen settings and varying PCI-e link widths, you could at least see if performance scales downward.

Not to bring up a "dirty" subject but this is where CPU rendered Geometry comes into play and why we have such a hard time with the sim as that is where the code was/is based and where more of it hopefully is now headed away from.Some links to read in your spare time:Nvidia New GPU Geometry rendering vs CPU 2004http://http.develope...ms2_part01.htmlhttp://http.develope..._chapter02.htmlCPU vs GPU Transforms:http://gamedev.stack...-the-cpu-vs-gpu