Blurries & contention

[Guest jcmckeown]

Wow! Christian I came to exactly the same conclusion by myself with the photo scenery I am using (see posts above). Actually my photo scenery has many of the small BMP files and was orginally developped for FS9 although the developper released a FSX patch (the scenery is still inherently a FS9 port).Regarding distant texture loading this is definately a recurring subject. Funnily enough, I can see that very far away mountains are better represented with SP1 than with RTM. The only problem is that all close up textures are completly messed up (i.e. not loading).I also agree with your comments on how SP1 seems to be coded. From the extra CPU bandwidth gained by ACES when moving to multicore support in SP1 I think the sim is trying to load more than the extra bandwidth it has got. If we all had quad or 8 core CPUs with huge photo sceneries it would probably work fine. However 1 extra core cannot absorb all the work that needs doing to load more distant textures and the close up stuff.With RTM CPU bandwidth was so scarce it was well prioritized in getting close up stuff loading first and then dealing with more distant stuff. If close ups were blurred you still had the fiber frame to play with. With SP1 the scond core gets bogged down at 100% utilisation and that's when things start to go horribly wrong. When I ran the tests for Phil on stock SP1 at KSEA, core 2 was peaking to 100% from time to time but was at 50% average. So the textures always stayed crisp & clear.If you get into a situation (and tileproxy will create this also) where core 2 gets stuck at 100%, you're stuffed.OK, that's enough speculation about things I don't fully understand, only ACES really understand what SP1 does...Rgds,JC

[Guest SIDDickDastardly]

Phil Taylor wrote:>Max LOD radius means we go out 4.5 tiles and load scenery>textures.>>If the 3rd party add-on is authored at the right LOD, then>Japan and the UK are indeed only 4.5 tiles away. Same with>Friday Harbor and Las Vegas, which is another case I have seen>mentioned.>>So I was wondering if we change to a lower LOD, does the>loading range drop and the file accesses decrease.I have the "Horizon Gen X" photo scenery installed for the UK (which was specifically designed for FSX). If I run Filemon and then fly over New Zealand (the furthest point on the planet from the UK) I can see many Gen X UK files being read, even when LOD is set to minimum and visibility is set to 20 miles. This seems to me to offer fairly conclusive evidence that there's a major bug in FSX relating to which textures are read. (Of course I can't prove that the appalling stuttering I've been getting with SP1 is caused by the fact that FSX is pointlessly loading textures from the other side of the planet, but I don't imagine the fact that it is doing so improves performance).The Gen X scenery is split into 9 areas which can be enabled independently in the scenery library. If no areas are enabled, performance with SP1 is reasonable. As more and more areas are enabled, more inappropriate texture access occurs and performance declines, even when flying on the other side of the planet to the area covered by the photoscenery. Prior to SP1, although unneeded textures were still being read, frame rates were far more stable.Cheers,DDMy system:Athlon XP3000+, nVidia 7600GS 512MB, 2GB RAM, XP SP2, DirectX 9.0c

[PhilTaylor 45]

What are you measuring here?File access rate, or total number of file accesses?Adam says this code hasnt changed in the fundamentals, so the total number of accesses to load a scene should be the same between RTM and SP1.If you set AffinityMask to 1, to disable the other cores, does that make the file access rate match RTM?That would make sense, since the file load rate has increased due to multithreading ( we process more at once ), but the total accesses should not be hugely different. And setting AffinityMask to 1 should make blurries worse, since the backlog should increase and thus the time for blurries to clear should be longer.This would also explain why people with fast ( 10,000RPM ) disks, some RAID0, are reporting they dont see this.

[Guest F900EX]

All I can say is this. I run FSX on the following PCIntel Q6700 CPU OCed/ Nvidia 8800GTX / 4GBs DDR2 RAM.. all high end hardware etc I spend $7000+ on a computer, when it comes to other pc games/sims i'm able to max out all the sliders and still get more then acceptable FPS.How come with FSX since day one, I have to spend more time tweaking, editing this and that, SP1 for me has been a complete joke. Blurries, stutters .. FS9 looked better. How I've been around Flightsim's since Flightpath 737 for the Vic-20, so I know how it goes. I just expected ALOT better performance then what i'm getting, and too add thats not with most of the sliders maxed out, no where near it. I love to know what PC Microsoft use to show the preview pictures just before FSX was released and get acceptable FPS... thats what I bought into, not this. I used to have the time to mess around, tweak settings I did not mind then, but things have changed and thats why I bought a Highend PC, "thinking" that most of these issues would not come up. I would like to ask is there any sign MS release another patch over the summer ?Thanks ...

[Guest jcmckeown]

I was monitoring the number of file accesses using Process Monitor. Around 600,000 for RTM and 1,200,000 for SP1 for the same test flight.Regarding the 10K RPM / RAID0 sorry but I have a WD Raptor 2x74GB RAID0 setup and have the blurries... I also tried putting the scenery files on a 7400 non RAID disk that did nothing to help.Rgds, JC

[Guest Robin R.]

Phil,10K rpm drives here, and I get them. For the heck of it, I used a 15k SCSI drive I have to see if that helped, nope -- still the same texture swapping problem.Are you checking for thread deadlock?Robin.

[Guest Robin R.]

Mega Scenery titles have the problem also (with or without their recommended optimizations) -- I know Phoenix does -- you can watch the shape shift mountians come in and out of focus as the textures are swapped.I've tested these on extreme systems also -- 15K rpm SCSI drives, 4GB PC10000 DDR2 with FSB over 1500Mhz and CPU at X6800 @ 4.4Ghz -- the problem does not go away. Also tried non-overclocked setups, same problem.But I thought Phil and others had already decided this "is by design"?? So is this not by design -- now I'm confused?So was this problem reported by anyone in the Beta group for SP1? If not, why not? Like I said, time to expand your Beta group or fire them all ;)Robin.

[Guest Robin R.]

Not defeated, but I had thought Phil and others indicated the "blurries" (aka texture swapping over LOD, no pun intended) is what it is "by design" to support some unlimited visibility concept within the confines of a 32bit address space?But if this is NOT by design, then I agree, obviously Phil's Beta group clearly didn't provide enough of a variance for testing and they should consider expanding and provide a debug build to those having the problem. Phil can take the results of from the debug build and see where there might be an issue they can resolve. But I don't think there is, this is how it was designed to work.But like I said, I understood this was by design and we just have to live with it. If that is the cause, lets not waste any more time on a product (FSX 32bit DX9) that for all intended purpose can NOT reach the "non-blurry" state without moving to 64bit address space and DX10. Spending more time on FSX really is kicking a dead horse -- lets move on to FSXI 64bit and DX10 - clearly that is where we need to be.Robin.

[n4gix 4,947]

>So was this problem reported by anyone in the Beta group for>SP1? If not, why not? Like I said, time to expand your Beta>group or fire them all ;)No reports were made, as Phil has repeatedly stated...Why would anyone report a non-existent problem?Most - if not all - third-party developers took part in beta testing; both commercial and freeware. Even scenery developers took part...Beta testing is a non-stipendary, volunteer position.As for limiting future FS development to 64-bit only, that's a "Bad Idea" of the worst kind. Why should MS limit their market to only the spoiled rich folks? Perhaps in another decade 64bit systems will have gained a majority market share, but that certainly is not the case today.

[michal 44]

>any more time on a product (FSX 32bit DX9) that for all>intended purpose can NOT reach the "non-blurry" state without>moving to 64bit address space and DX10. Spending more time on>FSX really is kicking a dead horse -- lets move on to FSXI>64bit and DX10 - clearly that is where we need to be.How many more times yet are you going to preach the same nonsense?Michael J.http://img142.imageshack.us/img142/9320/apollo17vf7.jpg

[Guest Robin R.]

More one liners - is that your contribution?What is your plan to fit that much texture detail into a 32bit address space and still have room for the OS and app code and ... The morphing/blurries combine with the "unlimited" visibility approach is the exact reason why texture swapping is happening - texture swapping = blurries.Please do enlighten me.

[PhilTaylor 45]

symptoms of thread deadlock are no terrain textures, and then a hang trying to change any terrain setting or world location. if you dont have that, you dont have thread deadlock.

[GHD 21]

>>What is your plan to fit that much texture detail into a 32bit>address space and still have room for the OS and app code>There is no need to fit detailed textures into memory, that is why mip-mapping is used.>>The morphing/blurries combine with the "unlimited" visibility>approach is the exact reason why texture swapping is happening>- texture swapping = blurries.>Unlimited visibility is effected by mip-mapping (less detailed textures)Texture swapping is not blurring, blurring is displaying lower level mip-maps closer to the view point.

[Bert Pieke 7,584]

Please re-read the above original posts.The issue we are trying to resolve is not the gradual blurring into the distance, but the inability of FSX to load detailed tiles right in front of the aircraft in real time.

[Guest Robin R.]

Microsoft have indicated no more 32bit OS's so hanging on to 32bit is futile.64bit CPUs are majority market share (even at the lower to mid end) - where are you getting your numbers from?? 64bit OS's from Microsoft took much longer to come out, but have also been around for a while now. Vista installs can be 32bit or 64bit so no additional cost there. Where are you coming up with "spoiled rich folks"?Ya know, this is sorta getting ridiculous -- person after person after person is spending a lot of their time diagnosing the "blurries" problem only to be confronted with "the problem doesn't exist". Countless images from real pilots and the not so real pilots have been displayed and yet you and a few others keep pretending their isn't a problem. Perhaps that IS the real problem.Trying to get the die-hards to admit to the "unlimited visibility" concept having the side affect of morphing scenery and texture mapping issues is like pulling teeth -- but eventually they do. Phil is the one that suggested a 64bit address space would be needed to stop the blurries IF unlimited visibility is to remain a design goal in the product.So what your saying is "live with it, I'm not ready to move to 64bit"? Microsoft limited their market share when they introduced Vista. Microsoft limited their market share when they made DX10 ONLY for Vista. So I really don't understand your comments unless they are purely selfish in nature and you have no interest is seeing FS grow to a more capable product."Beta testing is a non-stipendary, volunteer position." -- perhaps that is also part of the problem? Testing is a long, mundane, and tedious job that I doubt any "volunteer" could have or would have the amount of time and patients that is really needed to provide the most effecitve feedback.