Jump to content

MrRoper

Members
 View Profile  See their activity

  • Content Count

    79

  • Donations

    $0.00 

  • Joined

  • Last visited

Posts posted by MrRoper

  2. Posted

    It's very sad.

     

    Jet, are you able to answer for my 2 questions to Poul:

     

    1. Does VSync 1/2 RefreshRate in Inspector is necessary? I don't fly in full screen mode. Besides, if I'm not wrong, VSync decreases frames...am I right?

     

    2. Is it necessary to limit frames in FSX? When I do it in Inspector, I have few more frames (there is smoother).

     

    I'll be thankful.

     

    And what about with this:

     

    How it looks in your sim?

     

     

     

    Regards,

    Lucas

     

     

    Hi Lucas,

     

    I will attempt to help a little,

     

    1)

    If you run in windowed mode then you can leave V-sync at "application controlled" The nvidia Control Panel V-sync settings only work in full screen mode.

     

    2)

    Bear in mind I don't run DX10 currently (to many issues with it to use it full time) however you have to realise that when running the FSX limiter at unlimited you 'may' see blurry textures in certain situations. using the FSX limiter dedicates more time to the rendering engine hence the loss in FPS.

     

    You can gain these back by lowering your FIBER_FRAME_TIME_FRACTION  setting. You need to use this setting to balance the loss of FPS vs Blurring of ground textures.

     

    The benefit of using this and the FSX limiter is that FSX will allocate processor resources to texture rendering when your frame rate exceeds the limit you have set.

  6. Posted

    ...or Vista with and without the update. I'm not sure that any test is even needed, Chris, as that change will be in the W7 OS - which is (almost) universaly used - yet we still continue to experience the DX9 OOM issue - so it doesn't work very well. I just accept that has made some improvement - but not enough for FSX to become "immune".

     

    Switching gears to DX10 - I can't say that in no case will there be any OOM when using DX10, but I can't remember seeing a single one in the eighteen months that we've been using the repaired DX10 api, and that (just speculating here - no facts) because of Steve's recent progress (and resulting increase in his understanding of the DX10 side of FSX) - it is quite likely that we shall be rid of all of the DX10 issues in the near future: i.e. we will be using FSX/DX10 exactly the way in which the ACES Team envisaged it.

    Snip

    Totally agree Paul,

     

    Im sure the experience without this fix (if it is working in DX9) would be worse but we are still at the limits of what DX9 can do. The Fixer goes a long way to minimising this issue, and if i could sort out my cloud fps issue it would be turned on all the time!

     

    Lets all cross our fingers that P3D goes 64bit and then we can all keep the check marks enabled in the Scenery Configuration and fly to our hearts content! :)

  9. Posted

    First of all: Thank You very much for sharing the link above.

    Really appreciated.

    As pointed out though - i am no PC technical expert at all and hence i mentioned the links in my previous post.

    And as i am aware of the fact that various factors may come into play i also added at least two resources and not just one.

    But ... isn't the aspect of video memory "mirroring" or "copying of resources" also outlined in the link kindly priovided by You?

    I apologize in advance if i should mess things up here as i just took a quick look at the article - so maybe it could be clarified again by a person more technically advanced here.

     

    Nevertheless - and for whatever specific reason, which i sadly can't explain in a detailed way:

    DX10 and VAS "interact", "work" or however i should say differently than this is the case under DX9 and the chance of crashing into the 32bit given 4GB "wall" in FSX is lowered noticeably - hence lowering the chance of running into an OOM.

    Now as i can't really contribute anything new or anything else of which i consider to be useful to this interesting thread other than i did have already mentioned - i'd say ... be it from my side for now.

     

     Sounds interesting.

     

    Hi, Firstly you are correct that DX10 manages memory in a totally different way than DX9 and that DX10 reduces the VAS usage due to DX9 requiring a "Virtualized" copy of video memory.

     

    Quoting the document directly

     

     

    To address this problem, Microsoft is changing the way that the video memory manager maintains the content of video memory resources. This change is being made so that a permanent virtual address range does not have to be used for each virtualized allocation. With the new approach, only allocations that are created as "lockable" consume space in the virtual address space of the application. Allocations that are not created as "lockable" do not consume space. This approach significantly reduces the virtual address space that is used. Therefore, the application can run on large video memory configurations without reaching the limits.

     

    So memory allocations that are not marked as lockable are not copied. My point being that a 1:1 copy of video memory is unlikely to be maintained in the VAS unless all the allocated memory is marked as lockable.. This can be checked I with Intel GPA but its not something I have done as yet.

  10. Posted

    In my experience, it is an improvement of about 10% over Dx9 which, added to the fact that in Dx10 FSX will continue to function right up to the 4095th MB of VAS, is usually enough to keep it going when in Dx9 it would have stopped.

     

    Yep 10% would make sense, which means that 10% of memory being allocated is marked as lockable and being virtualized,

  11. Posted

    [...] The reason for the less OOM is apparently DX9 requires mirroring the video memory in FSX's virtual address space which is limited to 4GB and fills up fast with high powered scenery and aircraft. DX10 does not require that mirroring and I think I read may be more efficient overall in its memory use in the sim. I'm not sure about that part I just seem to remember reading it. The video memory mirroring is for sure accurate [..]

     

    Thats not exactly true, since WDDM 1.1 and vista

     

    http://support.microsoft.com/kb/940105

     

    However the Gist is along the right lines ;) and as we dont know what FSX is doing with its memory (i.e. marking the buffers as lockable or not you will get a benefit from using dx10

     

    It shouldnt be gigabytes though on a modern 64bit operating system

  13. Posted

    Hmmm.. No problem, Chris: reading responses like yours is great, because always promts a re-evaluation of earlier conclusions - which can be wrong, or can be misunderstood easily on a forum, and with an answer which is insufficiently clear. I'm 100% sure that not many folks understand buffers, and while being greatful to Bojote for his pioneering research - his original posts were not as "correct" as Steve's "hands-on" documentation has shown. Steve's blog is very clear, and my own dabbling has merely borne out his documentation.

     

    "use Intel GPA to track VertexBuffer usage" - yes, this is the way to see the evidence, and understand how the system responds for sure.

     

    I run water at 5 or 6 without penalty, Chris, but - given a 780 and a "relatively slow" (see note below) processor - why would you not run UsePools=0 and let the 780 run free? I suspect you wouldn't have a water problem unless there's something else going on in your pc. The early Bojote mantra that the ground flashing which resulted from UsePools=0 isn't there when using DX10. Are you running DX10?

     

     

    "and that it is much quicker to search and track one large buffer than many small buffers."  True - when FSX is doing it - but you have a 780, and that beast will search and find far faster than FSX can supply data.  If you had a 580 instead of the 780 - using UsePools=1 and a small RT makes sense, and this worked for me, too, but when the 780 went in - within a week it became UsePools=0.

     

    "Note below"

    My remark about the "relatively slow" processor is based on the FSX architecture being more suited for single-thread computing and is not a 100% multi-threading application. It think the SB at 4.8 - 5.0+ yields a much higher FSX performance than does the IB. I've seen a number of folks claim that the IB at 4.6 is the equivalent of a SB at 5.3+. It may be, if one is interfacing a browser-based, multi-threaded, multi-user business application as a front-end to an Oracle database. But this is FSX.

     

    Anyway - good subject, and interesting to get another viewpoint!

     

    All the Best,

     

    pj

    Hi Paul,

     

    No I don't run DX10, mainly due to issues with heavy cloud and stutter which I have not resolved as yet and as you said in DX10 the issue with corrupt objects is not apparent and I would be able to run a lower water setting and turn off shared buffer pools.  However I can demonstrate easily the cost of running High water (In DX9) as the FSX engine has to render the scene twice so that it can apply the reflection textures to the water.

     

    I appreciate that as a DX10 discussion this was probably off topic as my case is particular to DX9, just wanting to point out that a "BufferPool" is just a large VertexBuffer with many objects in it as apposed to bypassing the bufferpool which is just lots of VertexBuffers with an object in each

     

    And I agree its a very interesting subject :)

  14. Posted

    Turning down the details does not *fix* the problem, it only delays the inevitable. It may be possible to turn down the settings enough that the risk of an OOM is very low, but the risk will always be there given the "right" (or wrong) conditions.

     

    And as I said in a commercial environment where the Sim is being restarted for different scenarios this low risk is acceptable as its VERY unlikely to happen. What we don't know is how much LM are committed to the entertainments market where people are running resource hungry scenery and aircraft.

     

    Don't get me wrong I want a 64bit version of fsx as much as the next man!

  15. Posted

    I can't feel happy about the situation as there are many add-ons and features I enjoy in FSX/P3D. It's also frustrating because as I customer, I don't know whether some of the amazing new v2-optimized add-ons like OrbX NorCal are "safe" investments at this time.

     

    The situation right now is not good and LM need to provide a better answer than "Our simulator is designed for many different usage patterns". Clearly they did not design the simulator around the idea that it should unceremoniously crash to the desktop with a misleading error message if you're using it "wrong". Stability should be the #1 priority for the professional market they cater to, and 64-bit is the only way to achieve that. X-Plane proves this beyond any doubt - 10.25 has been absolutely incredible in terms of stability for me.

     

    The move to 64-bit needs to come sooner rather than later. 64-bit should not break "traditional" add-ons, only those that rely on external .dll's and modules. Most of those already broke when they moved to 2.x / DX11, so now is as good a time as any for LM to make the switch.

     

    I remain hopeful that they will be able to plug a few memory leaks and optimize the loading/unloading of scenery data to keep the sim going through 2014 in its current 32-bit state.

     

     

    But their target audience wont be running memory intensive add-ons with high-res VC cockpits. Also not many long haul flights are performed in a commercial sim, I can imagine that P3d as it stands in a typical commercial usage scenario performs very well

    I think that until P3D will switch to 64 bits, X-Plane has maybe a unique window of opportunity to become a real competitor in terms of sales/community adoption.

     

    This will depend on how quickly the most requested missing features will be implemented in X-Plane.

     

    I agree, but I worry that they dont have the resources available to pull something out of the bag quick enough

  16. Posted

     

     


    While I am, for sure, no Guru on BP - but I have studied the differences between DX9 and DX10 graphics, and how the system works in order to come up with the BP doc, and to date no-one has offered to correct any "wrongness" which may exist therein. I have to say, too - I am fully open to having the BP doc studied and corrected if necessary. It wouldn't be the first time I've been wrong in this or any other chunk of my life! then create a new buffer, BUF 2, and proceed to fill that one, and as many more as needed, static and dynamic, along with index buffers for same. In doing this with 100MB buffers FSX and/or the gpu (DX9 or DX10) has to contend with managing that volume of data in each buffer. 100 MB can contain a huge volume of vertex data, and I can only say that on your system (because everyone's system is different, and is configured differently, with thousands of different preferences) you are not very demanding in your "graphical needs", otherwise you would likely experience VRAM OOM's. I don't personally care about, or monitor VAS or VRAM. If I run out of VRAM the screen will tell me pretty quickly, and only with the earlier < 1GB vram GPU's and DX9 did this ever happen.

     

    Hi Paul,

    my response was in no way an attempt to prove any wrongness in your document , just to point out that FSX (Certainly in DX9) will only create vertexbuffers when using a "managed" pool when it cannot find any room in any existing tracked dynamic VertexBuffer, and that it is much quicker to search and track one large buffer than many small buffers.

     

    While this could result in memory waste, at the most this waste will only be (100MB - vertex data size) if our buffer pool setting was 100mb. The real way to balance this is to use Intel GPA to track VertexBuffer usage depending on settings and set the bufferpool size accordingly.

     

    The reason I rather do this is so that I don't have to run my water at 2xHigh that is required when not using a shared buffer as i found the FPS hit to be quite high ( I appreciate that this is not needed in dx10!)

     

    There are a few caveats to this, I run quite an aggressive RejectThreshold that means that the majority of objects are given dedicated vertexbuffers which lowers the usage of the shared buffer(s) and I also have quite a powerful machine (ivybridge at 4.5ghz and a GTX 780)

     

    Regards

    Chris

  17. Posted

     

    Wrong - yes - your [bufferPool] number of 100000000. These are bytes, which will make 95.36743164063 MB - not a very "round" computer size, nor is it very useable as a buffer, as 10 buffers at that size will take up almost 1 GB of allocated vram. FSX will want much more than 10 buffers.

     

    Hi Paul,

     

    I dont think this is correct, FSX will only create vertex buffers when it cant find space in any existing buffer within the pool, In-fact I run DX9 with a buffer pool of 100MB  and never see my VRAM go above 1GB in 3rd party scenery with Dense / Very Dense autogen.

     

    In my testing it is obvious that a Large buffer pool performs better than many small pools. I do appreciate however that this might not be the case in DX10

  18. Posted

    I guess just a few rubber bands is all that's needed?  I can say roll is very smooth but elevator not good.  Does this mode impact this, if so by what mechanism?  It doesn't seem like it is affecting the friction between the shaft and bushings and I don't see how something else would cause the subtle 'catch and release' that one feels when push/pulling.

    Do any Cessna yoke owners or other Saitek know why every time I start P3D now the Cessna Trim wheel loses its USB connectivity.   It's present in the P3D control dialogue, but if you turn the wheel it doesn't pick it up.  Pulling and replugging its USB connector re-activates it.   Any ideas on how to restore this to normal functionality?  I worked fine yesterday w/ several reboots, not today w/o the USB unplug/plug routine.

     

    The MOD makes the world of difference, Remove a few plastic brackets and replace with rubber bands..The center detent is still there but nowhere near as bad, I did mine a few years ago and it made a HUGE difference.

     

    Make sure you get some good chain lube and give it a spray while its open as well. :)

  25. Posted

    Hey Chris, the overclock has been running for nearly 4 years now. Overclockers.co.uk selected the chip and did the clock through the bios.   I also bench tested it with prime95 & CPUID CPU-Z when it arrived.

     

    After modifying the cfg and tweaking  the sim runs beautifully, so far I have done OMDB - VIDP - EDDP & now enroute to KJFK, not a single issue.  

     

    It could also have been the GPU drivers I was using.

     

    Anyway, thanks for the help guy's! I am blown away by this sim :) 777,EZDOK,ASN,OPUS,FTX, REX Direct, Shade and SimPhysics all running ultra smooth.  

     

    The Titan made a huge difference compared to my GTX670,  can't understand why some would say it's not worth upgrading the GPU for FSX.

     

    Cheers

     

    Ah ok, yes could have been the drivers... Blue screens are normally caused by Hardware issues.

     

    Aentwis,

     

    yep, correct usepools/bufferpools = 0 will create the buffers directly in GPU memory and bypass the reject threshold

×
×
  • Create New...