I'm Disappointed

[Robert McDonald 167]

Just a wake-up call here... 64bit will not make using 4096 textures easier or more possible. It just won't. I have no idea where people get the idea that it will.

 

Texture size is still primarily impacted by video memory size and access... of which it's not 64bit at all, but rather for PCIe-16 it's 16 serial connections used for access... and then you have to take into account pixel resolution times color depth... and then add in expanded resolutions to support more complex antialiasing... and... well, the video memory requirements grows exponentially and a 64bit program won't make one bit of difference. But... keep on deluding oneself. :wink:

 

Ed is quite right.  64-bits simply allows a program to access the entirety of SYSTEM RAM, be it 8GB, 16GB, 32GB or more... and thus obviates the danger or likelihood of "OOMS" in the VAS (Virtual Address Space).  However 64 bits itself does nothing for texture mapping, which is generally a function of the VRAM (Video Ram) on the GPU card(s).  Thus a card like the GTX Titan with 6GB of VRAM becomes much more important in P3D or XPlane10 than the raw issue of 32-bit vs. 64-bit operating systems and accompanying programs.

The migration to 64-bit will definitely have some VALUE long term, as machines continue to sport more and more system memory.  My own system has only 16GB of RAM, but 64-bit XPlane allows me to use almost all of it for programs (minus some for the Operating system and drivers), while the VAS inherent in 32-bit programs is limited to around 4GB or so, MAX.  When the graphics card has more VRAM available (Titan=6GB) than the underlying program (32-bit FSX or P3D), there is something to be gained by moving up to 64-bits.

 

But the poster is quite right, 64-bits ALONE will NOT be 'the magic bullet' that many pilots envision.  It just removes one of the uglier bottlenecks (VAS OOM-errors).  

 

If the work of drawing (rendering) the sim with all the add-ons can be divvied up via a network and spread out amongst several different PCs, I believe that is a great way to get more 'oomph' out of a simulation - I don't personally believe SLI-setups ALONE would be as robust as multiple PCs with individual CPU/GPU setups being tied together to render the airplane, scenery, instruments, and flight dynamics.  A mini rendering farm, if you will.

 

One of the P3D competitors has a great facility to divide work up over TCP/IP networks, and my great hope is that ultimately the LM team will fully implement such a scheme within P3D.  If that were to happen, the likelihood of a huge crush in pilots moving to P3D would be exponentially increased, IMHO. 

 

Why?  Because happy-meal PCs (say i5's with 1 PCI-e Slot) can be purchased, and upgraded to say a nVidia 4GB GTX 770 card and upgraded PS for about what a single GTX Titan costs (about $1000 USD).

 

Build 2 of those to supplement an i7 OC'ed to 4.7 or more Ghz, and you have a great graphics trio.  Then almost anything can run the glass cockpit server and say an all-in-one for the instruments/gauges, and you have a very flyable setup for something south of 5 figures.  And this can be built up over time, so you don't have to acquire everything all at the same moment.

 

So much as 64-bits has some appeal, the greater issue is to build a simulator that is easily scaled up to more component pieces, so that the overall task of rendering everything in real time can be shared among more than just ONE CPU!  Once the SLI-stuff comes online, the huge bottlenecks will be VAS, and the CPU, and in my mind, the CPU is going to be crushed by trying to do ALL the lifting on just ONE system.

 

As Rob Ainscough rightfully suggests, one still needs to turn a 'blind eye' to some portion of the sim experience, it simply isn't CGI-quality in real time YET.

 

That said, when you see a sim rendering in 48fps and above, you begin to become greedy and think about 'more spectacular' effects.

 

I can live without cloud shadows, though they are cool, no doubt.  What I really want is butter smooth 180-degree FOV across triple monitors at 1080p or higher, with all the eye candy and upgraded mesh, airports, yada yada!

 

Right now, for sheer beauty - P3D is the clear winner.  Hats off and Kudos to LM for this product, which is drop-dead gorgeous.

[denali 74]

 

 

it's not 64bit at all, but rather for PCIe-16 it's 16 serial connections used for access

 

I wanted to say something similar.  The bandwidth on hardware just isn't there for 64bit to make a difference now.  It's not just the size of your spigot, it's the size of your pipes that matter.  Single graphics cards don't quite have the pipes (because of mobo) yet to make that much of a difference.  If you SLI on the wrong motherboard you might as well just have one card.   

 

 

What I really want is butter smooth 180-degree FOV across triple monitors at 1080p or higher

 I have a triple monitor fisheye/stretch fix.  It's kind of hacky, but it works.  I"m trying to make it a bit less so.

[Brian Doney 127]

 

If you SLI on the wrong motherboard you might as well just have one card. 

 

 

I...guess so...but you'd have to be on some pretty old hardware for that to really become limiting.

 

http://www.techpowerup.com/reviews/Intel/Ivy_Bridge_PCI-Express_Scaling/23.html

 

If you're on something relatively modern I have a hard time seeing PCIe speed/bandwidth even entering the equation. After all, 3.0 is fast enough, and had enough bandwidth remaining, that AMD was able to drop crossfire bridges for the 290/290X.

 

My board is able to keep x16/x16 at 3.0, so ~1GB/s per lane in both directions, but even on boards that have to drop to x8/x8 I just can't see any issue there. 

 

Link speeds would still be faster than system RAM in most common configs. 

 

http://www.pcisig.com/news_room/faqs/pcie3.0_faq/#EQ2

[Robert McDonald 167]

 

 

Robert McDonald, on 18 Apr 2014 - 4:35 PM, said:

What I really want is butter smooth 180-degree FOV across triple monitors at 1080p or higher
 I have a triple monitor fisheye/stretch fix.  It's kind of hacky, but it works.  I"m trying to make it a bit less so.

 

 

I went 3 pcs 3 GPUS instead of trying to stretch it across 3 monitors from 1 graphics card.  Using Multi-Player (as LM removed "Multi-Channel" from 3PD AFAIK).  On YouTube, I have the camera.cfg files posted for all 3 monitors (1 file for each of the three pcs).

[jabloomf1230 2,452]

Just a wake-up call here... 64bit will not make using 4096 textures easier or more possible. It just won't. I have no idea where people get the idea that it will.

 

Texture size is still primarily impacted by video memory size and access... of which it's not 64bit at all, but rather for PCIe-16 it's 16 serial connections used for access... and then you have to take into account pixel resolution times color depth... and then add in expanded resolutions to support more complex antialiasing... and... well, the video memory requirements grows exponentially and a 64bit program won't make one bit of difference. But... keep on deluding oneself. :wink:

 

The whole 64 bit 'thing" is just a convenient excuse for some people to use to rationalize staying with their present sim and not switching to P3d. I've posted similar statements as to what you wrote before and I don't think it convinced any of them. I think what did convince some people recently is that P3d 2.2 got rid of the OOM problem without going to 64 bits. How is that even possible? :t0152: 

[Brian Doney 127]

Texture size is still primarily impacted by video memory size and access... of which it's not 64bit at all, but rather for PCIe-16 it's 16 serial connections used for access... 

 

I'm really not trying to be pedantic ( no really, I'm not ), but this line confuses me a bit.

 

How are PCIe and 64 bit memory addressing comparable in this way ?

 

For the record, the R9 290/290X sport 8 64bit memory controllers, but again I'm not sure how that relates.

[hopskip 253]

The whole 64 bit 'thing" is just a convenient excuse for some people to use to rationalize staying with their present sim and not switching to P3d. I've posted similar statements as to what you wrote before and I don't think it convinced any of them. I think what did convince some people recently is that P3d 2.2 got rid of the OOM problem without going to 64 bits. How is that even possible? :t0152: 

 

It's removing unused addresses better.

 

Stick PMDG 777 (-300ER with it's GMCS and Weather Radar) into an Orbx scenery with ActiveSky Next, photoreal scenery for huge swathes of the world... 

 

Suddenly in FSX land you're pushing 3.8GB VAS in the first minute after loading. Change views a few times, logon to VATSIM during Cross the pond and try to run an 8 hour flight out of an Aerosoft German airport, over NL2000 Netherlands, Over Orbx FTX England, Over Orbx Cardiff airport, over Eiresim Dublin, up past a photoreal Greenland, and into FSDT Chicago with all kinds of North American scenery and/or photoreals running?

 

Not possible in FSX. And I'd say there are some points in time (Particularly over NL2000 and Aerosoft Amsterdam together) where the actual IN USE virtual addressing space is bigger than 4gb, at which time "Out of Memory Error".

 

the 32bit space has a hard limit. If you go 1 byte over that limit, Out of Memory Error, regardless of real actual RAM on the machine.

 

Imagine: You have 2 digits available to express any number.

 

you can express -9 through 00 up to a maximum of 99

 

99+1 = Error, because the number 100 needs 3 digits, and you only have 2. 99+1=100 but this will appear to be 99+1=00

[WarpD 824]

hopskip... the situation you 'paint' is a flaw in all the addons, not the base sim itself. There are ways to ensure that your addons don't eat up the VAS... but people (developers) really don't pay attention to it, thinking it's a non-issue.

 

Moving to 64bit just hides the actual problem... it fixes nothing.

[Robert McDonald 167]

hopskip... the situation you 'paint' is a flaw in all the addons, not the base sim itself. There are ways to ensure that your addons don't eat up the VAS... but people (developers) really don't pay attention to it, thinking it's a non-issue.

 

Moving to 64bit just hides the actual problem... it fixes nothing.

 

Again, well-said.  Sloppy coding is something that's never good, particularly egregious when you have a pilot on a multi-hour flight that suddenly crashes due to VAS overload.  64-bits doesn't 'fix' the sloppy code - but it can appear to by 'hiding' the problem, as you correctly postulate.

[WarpD 824]

I'm really not trying to be pedantic ( no really, I'm not ), but this line confuses me a bit.

 

How are PCIe and 64 bit memory addressing comparable in this way ?

 

For the record, the R9 290/290X sport 8 64bit memory controllers, but again I'm not sure how that relates.

How are they comparable? Texture size is a factor for two things... how much memory you have on your video card and what is the transfer bandwidth between your motherboard and your video card. Let's say you're using all 4096x4096 textures. So, each texture 'sheet' is 4096x4096 pixels in size... which is a total of 16,777,216 pixels. Assuming 32-bit color... that's 4 bytes per pixel so it ends up being a total of 67,108,864 bytes of memory... for one texture 'sheet'. Based on that size alone... a 2GB memory card has enough memory to store 29 4Kx4K texture sheets in it's video memory... and that uses up all of the memory without actually doing any image rendering. So... we'll assume we're not going to use up all of the memory and maybe only use 10 texture 'sheets' in our video images.

 

For a single monitor at 1920x1080x32bit... you need 8,294,400 bytes of video memory to generate the image.

 

And at no point have I even touched on the memory cost of antialiasing.

 

When you're using textures in the video card... they have to be transferred into the card's memory... via the PCIe-x16 bus... which is a serial bus, not parallel. So, it has a bandwidth as well. The more data you want to transfer through that bus... the bigger the performance impact.

 

And absolutely none of this is affected one bit by converting an application to 64bit!

[Brian Doney 127]

I don't really disagree with you on the necessity of 64-bit point, but I'm sorry, a 32GB/s bi-directional interface (PCIe 3.0 x16) (which, btw, is faster than every other interface in your machine, excepting some CPU caches and the typically many-times-faster VRAM bandwidth) has nothing to do, in any way, with 64 bit memory addressing, which is what you compared.

 

Please don't change my question into something I didn't ask. I didn't ask you if large textures require more VRAM, nor did I ask if anti-aliasing was expensive.

 

As far as bottlenecks go, PCIe just doesn't enter the equation. It is more than fast enough. 3.0 brought impressive overhead reductions as well, but even without is still orders of magnitude away from being a concern. I'm also not sure why you mention that PCIe is serial, multi-lane link interleaving allows successive bytes to be sent via successive lanes, which again, for 3.0 x16, means 16 lanes at 1GB/s each, both directions, with overhead <2%. So yeah, there is a bandwidth, but it's wide enough.

 

If your point is that VRAM capacity might be an issue with excessive use of 4096 textures/anti-aliasing, well yeah, obviously, but again, that's not what I was asking, and still has nothing to do with PCIe.

 

I'm sorry, but what you said still doesn't make any sense to me. When a texture of any size gets sent to the GPU, the fastest part of that trip will be over the PCIe interface. I'm really not trying to start an argument here with you, but I just can't see how PCIe comes into it.

[WarpD 824]

So... just because the physical interface can do a 1 gb/s transfer... to you that's a zero impact zone? If only that were indeed true. Transferring data is never, absolutely not ever a zero impact zone.

 

In a simulation environment... microseconds count, a lot. As I've already stated... the primary bottleneck will be between the CPU and the GPU (even moreso if you add in drive access times which is yet another discussion altogether). That's not going to change by converting the base sim code over to 64bit.

 

I am totally amused by this belief that 1 gb/s means there is no bandwidth issue. Reminds me of when the IBM PC XT came out at 1 MHz CPU speed... and a 10 megabyte hard drive. I believe the claims then were that we'll never need more than 640k of memory and that hard drive is more than enough storage space... let alone how fast that computer was!!!

 

Not everyone is running PCI 3.0, not everyone is running a 4ghz CPU, not everyone is running an SSD drive. So, the primary chokepoints are going to be DRIVE>CPU<>GPU. I've already seen posts where people state their CPU is maxed out and their GPU is running at 40% with Prepar3d 2.2... which tells me that they have a bottleneck between their CPU and their GPU and they just can't get information to the GPU fast enough.

 

I remember in the late 80's I had a client that wanted faster internet access to his office. He purchased an ISDN interface that was supposed to run at 128 kb/s... problem was... everything after his ISP's connection was 56 kb/s... so he was paying a lot of money for fast access to exactly 1 hop, from his ISDN modem to his ISP's bridge connection.

 

It's not always about how much physical bandwidth can the pipe support... it's also about how much can the rest of the equipment on either side support.

[Brian Doney 127]

What are you talking about Ed ?

 

Really ?

 

The last two posts from you, have both completely sidestepped the question I asked you. You are completely wrong, in every way you have tried to analogize, about the PCIe interface, and in both posts, you've just randomly changed the subject to things completely unrelated to the question. I think that's because you know that you're wrong, but just don't want to admit it.

 

I posted a few links on the previous page you should really take a good look at. The very fact that you bring up that "Not everyone is running PCI (sic) 3.0", is evidence enough that you do not understand the point you're trying to argue. 2.0 is more than fast enough as well. 

 

Are we going to go back to 1.0\1.1 ? (which btw, is still mostly fast enough)

 

PC XT ? ISDN ? Ummm....what ? Why are we talking about 30 year old tech ? You aren't somehow conflating PCIe and PCI are you ?

 

Moving on to your example, if the CPU is maxed out, along with low-ish GPU utilization, that's a classic CPU limited scenario ! "CPU is maxed out" pretty much tells the story there, and still has nothing to do with PCIe. Did you really think PCIe was the issue here ?

 

You specifically said the PCIe was a problem, and now that we've gotten past that as ridiculous, now you want to shift goal posts to the "rest of the equipment on the other side"...yeah no kidding ! PCIe, for the last time, is an interface for transferring data, and is the fastest in your entire system. 

 

Fast enough, as I posted yesterday, that AMD was able to do away with crossfire bridges and send everything between cards directly over PCIe for 290/290X. 

 

I know this post sounds a bit on edge, and I apologize for that, but that's because you aren't doing your due diligence to check into this stuff on your own. You've made some incorrect assumptions and are arguing with me based on them, and that's just a waste of everyone's time.

 

Just let it go. Go enjoy the weekend, if you celebrate, then have a Happy Easter. This argument is over.

 

Maybe we should change the subject now, I suggest the hidden dangers of the AGP interface.

[WarpD 824]

I know this post sounds a bit on edge

Actually... you're downright frothing at the virtual mouth at this point... and becoming rudely condescending.

 

A shame really... are you that way in person?

[Brian Doney 127]

Happy Easter Ed.

 

There would likely be less of an aggressive tone in my posts, if you could actually have been bothered to read what was being posted, and I already did apologize for that, but I will say it's a bit rich reading you complain about someone else being condescending. 

 

Pot meet kettle. 

 

In any case, I'll assume that with another non-reply from you, this last having clearly moved into the realm of the ad hominem, that this discussion is now closed.

 

I don't want there to be bad blood, but you know, a little humility on your part, when you are out of your depth, would go a long way. 

 

If simply stating flat out that you are, and were, wrong, is considered "frothing at the mouth", then so be it. You had a couple of chances to check yourself, but instead you decided to double down. That's not my fault. I'd suggest that if you really do have any further issues with my posts, you contact a moderator and let them handle it.  

 

There is also the ignore list. Feel free to add me to yours.  :unknw:

 

To any moderators and the rest of the forum, I am more than comfortable with resting my case here, and will not contribute any further to derailing this thread. It should be pretty easy to determine the facts for anyone that is actually interested. We now (hopefully) return to your regularly scheduled programming.