All Your VRAM Is Belonging To Us (and Plugins)

148 comments on “All Your VRAM Is Belonging To Us (and Plugins)”

1. There are other games out there that use Metal and do work great, for example World of Warcraft, so it should be possible to solve your problem. Maybe ask the internet community for help? Or open a ticket with Apple DTS?

   1. I agree but, here we have a different situation. Other games were coded from the beginning as a Vulkan/Metal, and X-Plane is moving from a old API with a lot of limitations.

      The worst problem is keep OpenGL running together because of Add-ons and plug-ins.

      I honestly think the best solution was release a Vulkan/Metal with a new X-Plane version (12), because by this way the developers can move from OpenGL to Vulkan/Metal and X-Plane can run just this API leaving OpenGL on older versions (…10, 11).

      1. You are right that X-Plane has a very different situations from other games, but “being an old OpenGL app” _isn’t_ the problem!

         At this point, we are _not_ an OpenGL app. The level of rewrites, modernizations, fundamental changes and code updates is so extensive inside X-Plane (and this is why this was a multi-year project and not a multi-week project) that we are really not being shackled by past GL-centric design decisions.

         I expect to support OpenGL in plugins _indefinitely_, even when the sim someday _only_ runs on Vulkan and Metal, because OpenGL is actually a pretty good API choice for things like 2-d EFIS panels.

         When we run in Vulkan/Metal with a GL plugin, plugins live in their own OpenGL sand-box, and the surfaces they render to are shared between Vulkan/Metal for our use and GL for their use. This bridge doesn’t affect X-Plane itself because it’s not on the main path of anything we do – it’s just an option we set on a small number of our textures at our own internal API level – “this texture is bridgeable”.

      2. The is another difference between X-Plane and “games”: “scenery” for games is usually very specifically designed to avoid overloading of the rendering engine. Authoring tools for those provide means to design for a limited number of assets visible from any given spot in the game.
         In X-plane its quite different – orthosceneries or overlays created the way W4XP does are notorious for how unrestrained they are at what they throw at the rendering engine.
         WED may at some point offer some tools to visualize texture and/or geometry density caused by a scenery – but I’m also expecteding protest like “Stupid WED doesn’t want me to place all that stuff I neeeeed there. It works fine for me with just stock XP installed, so it can not possibly be a problem”. The overlay scenery concept makes it really hard to assess what other default or 3rd party stuff will be near or underneath any given overlay scenery for any given X-Plane user.

         1. Exactly. X-Plane has to treat scenery the way a platform treats apps. In a closed game, the test team finds a perf problem, and then one of the coders looks at it and maybe walks over to the level-designers cubicle and goes “hey, you’re KILLING us with the 3000 dynamic lights – they don’t play well with the 200 real-time environment probes” and the art guy discusses work-arounds with the programmer, knowing the perf of that particular engine at that time and they sand it down.

   2. Hey Ben thanks for all the info you gave us, but let me ask you something. Will be great if xplane11 could have the option to choose between what WX SOURCE do we want, ex: vatsim IVAO, noaa and plane source indeed. All of this because I fly in an virtual airline and the baro pressure and temperature unmatched with the reality a lot when xplane is at real world weather conditions, another thing is about the software all virtual pilots use like SIM ACARS if you don’t have the real wx conditions set on your plane sim acars could penalty for the discrepancy.
      Will be possible to choose the wx source from IVAO VATSIM NOAA AND XPLANE DEFAULT in a future on xplane? Thanks in advance

      1. This seems like something an add-on should do. There are already good interfaces to either write static weather with datarefs OR write localized weather with METARs and GRIB2 files. An add-on that provides this data (and some already do) can tell X-Plane “hey use the weather I just gave you.”

         It’s not our place to go call up VATSIM’s servers and get their weather – that’s for XSB to do.

         1. Weather injection is seriously limited in XP11: I’ll agree plugins should be responsible for gathering from a variety of sources, but setting datarefs for local weather completely breaks enroute ATIS and doesn’t allow for transitions. Setting the world with METAR and grib files is a partial solution. Laminar’s current dataset is hours old. Eventually, richer API would allow modeled weather to actually match real, current weather, so flight planning using external tools better predicts simulated flying weather.

            But, don’t worry about that — Vulkan first!!

      2. Yes, the plugin could write the weather files (if they aren’t locked in Windows) and then (preferably via some API) tell X-Plane to re-read those files (assuming real-weather download is disabled). I guess such API already exists.

2. Many users have lots more system memory than VRAM. The system I’m typing on has 32 GB of system memory but only 8 GB of VRAM. I can see keeping as many textures as possible in system memory, in both hires and lores formats, and then moving them to VRAM as needed, minimizing the need to hit file storage. I can even see multiple strategies to handle this based on user preferences. The trick is balancing all that and minimizing transfers to VRAM. It’s a “fun” process.

   1. Our plan is to page the high-res ones all the way out to disk – people have lots of RAM but they also have SSDs, and the paging is _async_ so the latency of disk access might not be the worst. (This is also how orthophoto packs already work so have some hope for it.)

      Theoretically one could page to RAM to get lower page-back times…if the texture is really hot and you have the extra system memory, the OS might just keep the texture in the disk cache (in RAM) and you’ll get the win…by not allocating specific RAM for the backing, we don’t have to worry that something we needed in system memory gets paged to disk.

      1. Re-reading from disk is in most cases (even with a very slow disk) essentially the same as caching something in application managed virtual memory. On top of what Ben mentioned its also in nearly all cases *TWICE* as RAM efficient as caching it locally in the app:
         Any contemporary OS will use unallocated RAM to cache disk content previously read.
         Keeping a copy in local virtual memory would be unknown to the OS and thus duplicate that content: Once in app memory plus in the OS disk cache.
         Re-opening a file with a memory-mapped disk read (which is what X-Plane and WED do in virtually all cases) is speed-wise very much the same than accessing any other cache of a file kept in the applications virtual memory space. But it avoids the duplication in RAM and it avoids the OS having to write that virtual memory cache to swapspace, if RAM gets tight – as it can rather be read back from the file system when needed in RAM again.

         1. So very fast storage to install XP is highly recommended, I guess, Something like NVME with good specs.

            Maybe in the future X-Plane will store/offload textures to a “raw device” to even have faster performance 🙂 (joke).

            Thanks for the insight.

            1. I’d say having as much data as possible on SSD is good, but it doesn’t have to be everything – if you had the sim, aircraft and OS on SSD but scenery on spinning rust, it’s not going to kill anything other than your initial load time, as the scenery pager can live with orthophoto scenery paging in with latency. And SSD is pretty fast – NVME and such are nice, but I don’t want anyone to think that if they “just” put an SSD over SATA it’s going to be a perf bottleneck.

      2. When you would read & write to an anonymous memory-mapped file, leaving actual disk writing and buffering to the OS, would’ you get async writes and buffering fir free?

         1. Writes, yes, reads, no, but it doesn’t really matter – the texture paging and load path is already _entirely_ async by us – we don’t keep you waiting while we process texture data with the CPU, DMA it to the GPU, read from disk or any of it.

3. A toast for Sidney!!!

   I hope user not to saturate your patience with “blurry textures” bugs.

   Ps.: When will be next features info for X-Plane be shared (If they can be shared)? I hope soon 🙂 . Sorry for the insistence.

   Thank you all for this great simulator!

4. I’m assuming this is the primary cause of visual stuttering. I have frequently noticed stutters when panning a cockpit view around in a large city. Or in other words, accessing autogen textures that I always presumed were already safely cached in VRAM vis a vis instancing. Is this a different OpenGL issue (OGL only ever has one issue, right ;)?

   Will the new methods use more PCIe bandwidth? Not to trigger more “why doesn’t XP make my computer blow smoke” comments, but I’ve never seen PCIe bandwidth usage rise above 50%, if that. Certainly there’s no PCIe spec that could rescue OpenGL from those dark ages of paging stutters. I wonder if there has ever been a real-life game usage for PCIe3.0, let alone 4…

   1. If you’re _not flying_ (e.g. sim paused) and you move the camera and stutter, it’s very likely to be VRAM, particularly when you have more textures loaded than VRAM can handle.

      While flying we’ve seen other sources of stutters:
      – Tearing down autogen was actually a stutter because we didn’t break the process into small pieces.
      – We’ve seen the windows allocator lock up when DSFs are being loaded and AG is being built.
      – The GL driver usually has to have internal locks that can be contested between rendering and loading DSFs/building autogen.
      – When you hit a new shader in 11.41 and it needs to be compiled, that’s a stutter, particularly at the start of flight – once you’ve been flying a while this stops happening.
      – Planet loads can stutter.

      I’m not sure the new methods will use more PCIe bandwidth than paging – we’re certainly not afraid to have paging activity going on _all_ the time.

      Something to think about with framerate: your computer has to be spec’d out to handle the _highest peak_ load that the engine puts out during transient stressful events (E.g. a DSF load or texture page or whatever). This means that if you want a steady even framerate, inevitably your computer will not be used 100% all of the time.

      Imagine if you were flying and, magically, everything was maxed out – CPU cores, the GPU in all aspects, all busses, we’re at redline. Then we hit a DSF boundary and we need some bandwidth and CPU cores to load a DSF. Where does it come from? FPS would have to go down.

      We realized this while moving things to be “in the background” to get rid of stutters. Our thinking (and I _think_ Sidney has a prototype of this already running in the 11.50 developer preview) is to allocate some cores for per-frame work (AI planes, water, maintaining DSFs) and others for background loading of scenery, with some rules to let each set of cores help the other. That way a DSF load doesn’t absolutely tank FPS, and high rendering load doesn’t delay scenery.

      1. Very interesting write up!

         I am a bit confused about the fear of framerate going down. As long as this happens smoothly (as in no stutter) I don´t see this as a problem?

         If I run around 40fps and then my framerate dips to 25 smoothly and later recovers – thats fine! I don´t want my framerate to be locked at 25 for the whole session just because I MIGHT encounter a scenario where this is all my computer can handle? In other words – I don´t want a “steady, even framerate”. I want the fastest smooth framerate that I can get in any given rendering-load situation (staying above the critical lowest-allowable framerat).
         Or did I misunderstand that?

         Cheers, Jan

         1. If the loss of framerate is steady, some users would be totally fine with that. There are two problems:
            – Some customers really want a fixed framerate. 60 fps, locked is a big thing for pro customers, and 60 fps gaming is a thing. VR customers (at 45 or 90) really don’t want to go below that number.
            – Loading activity can be intermittent, so the drop in FPS might not be a slow, steady ramp, so the transition to and from high fps might be really messy.

            1. ->VR customers (at 45 or 90) really don’t want to go below that number.

               But only because doing so makes us puke from motion sickness and nausea….

               could this blur v stutter thing be a preference setting?
               Out of VR the odd stutter is way easier to stomach than blurry textures.
               Inside (most current) VR blurry textures might not even be visible.

               People will definately have strong opinions on one the other or both.

               What’s going to be the best way to communicate “this blurry texture makes me sad” during the beta?

            2. No. No stutters. We’re going to try to minimize blurriness by using your VRAM as efficiently as possible. We are not going to write any new code that can stutter the sim during normal flight, ever again. (We’ve actually had that policy in place since mid-v10, but the Vulkan port is where we fixed the build-up of legacy stutters from older versions.)

               We have some internal tools to look at how X-Plane is managing VRAM – we’ll come up with a way to neatly package this before public beta so we can efficiently triage reports, the way we have with FPS reports and stutters.

            3. Thanks Ben, makes perfect sense.

               I got the impression that things “could” still stutter and there was some fine tuning ongoing as to how aggressive it needed to be when compressing them, I was just thinking it might make sense to have that fine tuning out in an art dataref similar to the others. “VRAM stutter prevention compress rate” inside/outside.

               Getting dynamic text to display well from planemaker panels is already a cat and mouse game, especially if there is any transparency. Making that text even more blurry would be a nightmare.

            4. You can mark your objects as “max res” in Plane-Maker and they don’t derez. This is true now and will be true in the future. As before, as an author, you just have to understand that if you make an airplane with a lot of ‘max res’ stuff, users with low-end systems are going to have a lousy visual look on _everything else_ because you nommed all their VRAM.

   2. The blurry texture thing i reconized not only at 11.50. From 2017 till 2019 the quality of textures decrease for me visible.
      Correct me if i am wrong but they was much better than now.
      Sometimes i departure with gorgeous textures and reflections, and after 3 Hours flight approaching destination the textures are horrible blurry / steped edges and sometimes reflections are also gone.
      And the clouds/layers are a so big FPS impact.
      Is the no better/faster way for cloud rendering ?

      Greets
      John

      1. I mean the 11.41r1 version.

      2. There is _no_ code to make textures blurry in 11.41 other than you changing the texture settings slider.

         1. No code “in X-Plane”: Some drivers may have performance tuning options that do that outside the control of X-Plane.

5. Today’s stupid question has arrived!
   Uhmm.. If it’s possible to predict texture use for VRAM, why isn’t it the same for plugins? Is that not possible to “buffer” the prediction of plugin VRAM use for a frame or two (or what is needed) and make it work together?
   Or a “prediction” of movement (like game servers, where server tries to guess where a subject is going).

   Okay you can start laughing now 😀

   1. For X-Plane we know our VRAM use because we loaded the data, and we load DSFs in front of you before you get there. For plugins, we don’t know what the plugin will do – it’s up to the plugin.

      1. What happens if I move the camera suddenly out of the boundry of the secenery? for example, make the camera go to a AI Plane that near the boundry

         1. Nothing – paging, cloud build-up, AG build-up and scenery load is based on the airplane, not the camera. That way if you go in circle view and spin like a madman at 10,000 mph far away from your aircraft you don’t thrash everything.

6. This is all music.
   The Vulkan API excels over OpenGL with its more inherent Asynchronous nature
   – Probably KHRONOS group should fire-brand as ASYN-KHRONOS 😉
   all is needed is a composer for the music/symphony, and scale-able optimized workload distribution, where the code should have some guessing logic to utilize the extra cores where possible (if cores available) and to pack the sub-processes on lesser cores as per available hardware.
   This video is a nice analogy how i imagine vulkan works
   https://www.youtube.com/watch?v=IvUU8joBb1Q

   Have you considered replacement of textures with procedural alternatives (where possible) ?

7. Ben, great detailed explanation! But there’s one thing re: view optimization that’s been bothering me for quite some time – actually for the two years that I’ve been enjoying VR now.

   I’ve noticed that the “distant viewing” distance is based on a straight line which is perpendicular to the direction of view. For example, when flying toward a mountain (as we all know) the mountain is rendered with an averaged mesh and reduced texture quality. Then as you get closer, the higher detail “fades in” to view. However, just as that starts to happen, if you shift your view right or left (probably 20 degrees or so) the mountain will show higher quality in the peripheral vision areas and as you turn again to look at the mountain, it goes back to the faded “overlay”.

   It seems to me that if you define the distance this occurs at in all directions from center of view (i.e. define it as a circular arch) instead of this straight line, you would gain a good bit of texture space where you _could_ draw a lower quality render, building up to a higher quality as this “distance of vision” line moves forward in the direction of flight.

   So I guess the question is, would this “circular” distance of vision be more impactful on the performance than would be gained?

   Just a thought.

   1. That last questions should have been, “…be more impactful on the performance than would be gained in texture management?”

   2. I don’t know why that would be happening – there are two criteria in the current sim going on:
      1. All fog and environmental effects are _radial_ – that is, distance to the point, which is the physically correct thing to do and fixes a bunch of weirdness that v10 had.
      2. The texture res for mip mapping is strictly based on how many pixels on screen the texture takes up – nothing we can do about that – that’s how the hw works.

      It’s possible that the headset resolution and lens correction warping is a factor here – that one is out of our control but at least gets better with new-gen headsets.

   3. +1
      time ago I filed a bug against that issue,
      objects seen at the edges of the screen are disappearing by turning the head in direction of the object.
      The object should be visable in the middle of the screenline instead.

   4. I have seen something similar (in VR). With limited visibility, a hill some km away looked hazy. when turning my head, the haze in the periphery of the headset decreased and the hill became more clearly visible.

8. Interesting read.

   However, visual stutters were never a problem on my system, which has 8GB of VRAM (Geforce 1080) and 32GB of RAM (plus a 8xxx Intel I7). I can get way above 50 FPS with any default aircraft at 4xSSAA+FXAA and full HD resolution in the default scenery. So I really do not know what you are talking about.

   The FPS hits (down to 25) start with more advanced planes like the FF A320 and more advanced autogen like X-Europe which X-Plane seems to be unable to handle.

   I would really hate to get blurry displays to fix a problem that I do not have.

   1. Right – and if we write our code properly you shouldn’t – for what it’s worth, we don’t see blurry stuff on 8 GB cards now even in the early developer preview. If you have so much VRAM that nothing needs to be swapped ever, both the GL and X-Plane strategies can work well by doing nothing. 🙂

9. Would it make sense to bring forward the plans for normal map compression? It doesn’t address any paging issues directly, but would surely be a big help in reducing potential blurries; the VRAM usage of some add-on aircraft and sceneries is a bit obscene.

   1. Normal map compression is a question of when, not if, cuz yeah – those 4K normal maps are crazy big in VRAM.

      This one is a little bit tricky because we’ve dumped our material maps (metalness, gloss) into the normal map, so we have to consider a few things:
      – If the texture is down-sized, at some point is the normal map useful? A normal map of rivets that is 4x down-sized is probably pointless.
      – Currently a down-sized normal map increases roughness where the normal map high frequency bumps used to be – this helps the lighting look better at far distances. How do we do that if the gloss map and normals are separated?
      – Which down-sizes first or more, the normal map or the gloss map?
      So there’s win to be had there, but we also have to decide how to set up the textures.

10. I would assume that shutter and frame drop loading and unloading textures is what kills my frame rates when I try to go beyond 500 knots in a fighter jet. My cpu is a i9700k intel, and my gpu is a 11gb vram seahawk, both are water cooled, so hardware isn’t the issue. I’m guessing it’s going to blur the scenery above those speeds, which is better then a momentary glitch. it’s disorienting when you glitch in a high speed turn all of a sudden the world shifts on you. I’m using four monitors and three computers so being surrounded by one glitch or another has me trying to correct a bank angle that isn’t off, it just appears to be when the glitch happens in the window you are looking out of.

    1. At high speeds in a fighter it might be autogen and scenery building – at high speed the autogen engine really gets the hell beaten out of it.

       1. LOL Thanks Ben!

       2. At those speeds in a real fighter, parts of the real world blur!

       3. I figured it out, I cut the traffic off and can hold a steady 45 fps, managed to push the Mig-29 to mach 2.4

11. Have you been tempted to title this “all your vram are belong to us”?

    1. I actually thought it was at first glance 😉

    2. If Ben wasn’t tempted writing it in the first place, I was very tempted to edit it last night.

12. Hey sorry so with current 11.41 do I need VRAM or paving file size set?

    I have 32 GB RAM. I have XEnviro and it causes stuttering! Whats the solution?

    Thank you

13. So is there an amount of VRAM that is sufficient to avoid texture blurring? Is 8Gb VRAM still not enough to avoid blurriness?

    1. Depends on your add-ons. 8 GB should probably be fine, 4 GB should probably be fine, but if you get an add-on that uses enough textures, you can always run out because Plane-Maker has no limit on how much authors can use.

14. I would Like you to clear a point of confusion, at least on my part. Does the new system. Look at how much VRAM a particular graphic system has and calculate usage load accordingly? Or do you calculate a base VRAM size and go from there? Also, do you support aggregate VRAM on multiple video cards? I ask because many of us with higher end systems. (In my case, 12 GB of VRAM for single video) and in the case of several of my friends and family have even more! Will we see less stuttering or memory swapping? Or do you Cap VRAM usage at a static level and swap anyway?

    1. We look at your hardware – Vulkan tells us how much VRAM is generally available to us.

       We do NOT support aggregate VRAM on multiple cards because we do not support multiple cards, and this is one of the big problems with multiple cards.

       If you have two GPUs, the VRAM for the second GPU is just as useless to the first GPU as your system memory – it’s not local to the first GPUs memory controller, and thus it’s not fast for sampling. This is one of multiple reasons why I keep saying that two cards for one monitor is silly – you’re getting half your VRAM killing power because half the VRAM isn’t on the memory bus of each GPU.

       1. to be fair highbandwidth SLI cards like the 2080 can use vram from the other card over the SLI bridge at nearly full bus speed to the GPU other things are helpful such as added ROP power for things like 4k
          and for VR SLI can be used in a case of GPU0 for left and GPU1 for right eye

          and if rumors are true and both nv and amd are going with chiplets you may have bite the bullet on multi gpu soon then later any way

15. This dynamic texture rescaling as needed is fairly common, and indeed can lead to users thinking it’s a bug. I suppose you keep track of which textures should be maintained at high resolution if possible, i.e. things in the cockpit rather than some scenery a couple of KM away.

    I guess some users need to have some kind of expectation level guidance as to the amount of VRAM needed on the texture resolution slider (Something GTA V had) but I imagine in X-Plane it’s much harder to know at that point.

    Texture popping (and to some extent LOD popping) are preferable to stutters, especially in VR…

    1. Right – we don’t exceed the texture slider, which can help to anchor the syste – if you have 1 GB you shouldn’t be running at the highest texture setting – by lowering the slider (just like you would in 11.40) you provide guidance to the sim “don’t even try to max this out” and avoid thrash. It’s easier for a closed game than for X-plane because we don’t know how heavy your third party add-ons are.

16. It is a bit funny. I left FSX for XP, one of the reasons (of course there were others much more important) was how i was tired of how blurred textures started appearing. And now in 2020, blurred textures strikes back on my new sim too 😛
    I hope you’ll manage to figure out how to introduce them without this feature doing too much damage. And without having Vulkan, a performance improvement upgrade, forcing me to change GPU (a think in the work, but equally funny if i have to do it based on an update which was supposed to improve performance on its own even tho more on the CPU side)

    1. If you don’t have blurriness now AND you don’t have massive stutters, you’ll be fine. It’s really only users who have sharp textures and massive stutters who might see a res loss, because they’re running way past their VRAM limit.

17. Ok, so I see that we have an elephant in the room here. I wonder if you can say anything about release of the beta. Are we talking about hours, days, weeks or months? If it is weeks or months away I don’t have to run the updater every hour to see if it is released.
    Thanks.

    1. Days/weeks, not hours/months.

       1. If we were to go by the book like Mr. Saavik…

18. The feeling I am getting is that the virtual memory could act like a buffer, I am no coder but that is what it feels like, so RAM is important, correct of say a base of 16gb, with 32gb as the nice round number to absorb the overflow. I already have an 8gb VRAM capacity so it already feels like a good set up to me. Will the texture quality slider disappear?

    1. The texture slider is not going away – it sets the maximum texture res we will try (and the final texture res when OpenGL is in use I _think_). So it serves as a useful rough calibration for us, e.g. if you have a 1 GB card and don’t set it to maxed out, we won’t go nuts trying to fit everything.

19. Blurry screen/text is my biggest issue – it’s not great in VR so reading your message was not good news for me….but I understand, it’s beta, it’s new and you are working on it. I won’t even pretend to admit in understanding 90% of what you have said, but I do appreciate your effort in tackling this problem. I also appreciate your honesty; at least we know what to expect. Great work – thank you

    1. Don’t panic! Certain textures are _not_ eligible to have res reduced at all. This includes UI, panel, etc.

       We ALREADY have this infrastructure in place so that when a user with a 1 GB card turns down the texture res, they don’t get an unusable aircraft. So we already have useful hints as to what has to be high res.

20. Hi Ben!
    Maybe a newbie question, but… does this mean that a SLI hardware config is now going to boost things up? (I think that before 11.50 this was no game changer at all).
    Keep up the great work!
    Diego.

    1. No. There is no change to our not supporting SLI.

21. Hi Ben.
    With respect to VR, since we are on the topic of texture sharpness etc, you might have noticed Nvidia has released a new driver allowing for foveated rendering at the centre of focus which can increase supersampling whilst increasing fps at the same time. I think this is called VRSS.
    It appears this might only be applicable to directx games. Are you guys in discussion with nvidia to see if this can be implemented in xplane for VR under vulcan?
    Every benefit we can get for VR we would like to take!
    Thanks

    1. VRSS is already available for Vulkan and OpenGL!

       https://www.khronos.org/registry/OpenGL/extensions/NV/NV_shading_rate_image.txt
       https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_NV_shading_rate_image

       So no barrier to us doing this.

       1. This would be awesame! Looking forward to this.

       2. Hi Ben,

          Just to clarify, are you saying that VRSS should be functional with XP? Also on the subject of Nvidia drivers are there any plans for a ‘Game Ready’ driver for XP?

          I currently fly in VR I can acheive 90fps plus fps in sim flying 2d and 40fps plus in VR which is acheivable and stable until I run into dense cloud where it begins to skip beats all over the shop. my system is an RTX2070 SUPER, I59600K, 16GB RAM should vulkan fix the stuttering I experience in VR around dense cloud etc?

          Also if the autogen gets to greedy with your CPU will Vulkan lower the number of world objects to offset the stuttering?

          1. I am NOT saying VRSS is functional in XP now. We are NOT using it.

             I AM saying that NVidia has specs for VRSS support for Vulkan and OpenGL, not just DX, so it doesn’t matter which API we pick (from a VRSS perspective.)

             I do not know whether support for VRSS in the drivers is finished or not. My guess is yes.

             Vulkan does not lower object count – note that autogen perf is not a stutter – it’s just low FPS. That’s because the cost of drawing that AG is the same every frame.

22. Hi Ben,

    TL;DR: pics plz!

    Thank you for another great Vulkan post. As as developer myself I can only agree with your post, especially the first part about human nature.

    Re: “so my fear is: users aren’t going to like it.”

    I walked into that trap so many times it’s not even funny. It’s one thing to listen to feedback, but it’s another thing trying to imagine what the users _might_ think. And here I am going to do it myself: IMHO it’s only is a matter of time when people start to think exactly in the same way about Vulkan as they did to OpenGL:

    from:
    Hey, I don’t like stutters. What can I do about it? Upgrade my hardware!
    to:
    Hey I don’t like blurry textures. What can I do about it? Upgrade my hardware!

    And of course, I fully understand it’s a long process of optimizations. If I compare the last versions of X-Plane I mean man, what a great job you guys did on performance. I’m sure it will be the same thing for Vulkan.

    So, my point being.. There is a choice between Vulkan and OpenGL right? So people can choose between stutters or blurry textures?

    But really my main question is: can you post a couple of screenshots with and without blurry textures to give us an indication of how “bad” the problem is at this time?

    Thanks again!

23. Some random thoughts:
    First, compression of textures takes place in VRAM completely and is done by the GPU, right? Otherwise it doesn’t make sense (moving the texture to RAM to be compressed by the CPU, and then being put back).
    Second: If you are looking forward for some time while moving in that direction, what will happen if you decide to have a look backwards? Is the change of view delayed until textures are ready, or will the new view be “enhanced” with (better) textures as they become ready?
    What about some (developer) option to omit any textures completely (any surface would be just some gray)? I think this was the way X-Plane 4 “Classic” loked like…
    Finally, I strongly dislike the long loading times. Is there a histogram of loading time per component? I’d prefer faster startup with textures appearing as they are loaded as you’ll have to prepare the flight anyway (not having time to look out of the window).
    If X-Plane displays s VRAM usage less than the VRAM on the card, does that mean no texture paging will happen, or is that number just a wild guess?
    Did you ever consider rendering hot keys, like the following?:
    * Disable/enable dynamic scenery
    * Disable/enable atmosphere effects (clouds, fog, rain, etc.)
    * Decrease/increase visible range
    At least such hot keys would very quickly indicate where the frame rate is burnt.

    And (completely independent of Vulcan discussion) my favourite:
    “Teleport into the plane that’s talking”, meaning you can control the plane that sent the last ATC message while your plane either continues with the last control input, or is taken over by AI.

    1. Compression and paging are completely orthogonal.

       Texture compression in this context means _lossy_ compression (e.g. DXT) – it’s basically another texture format with fewer bits per pixel. Textures are ideally compressed by the author and saved to disk compressed; if they’re not, they are currently compressed on the CPU in a background thread (e.g. we load the RGB data, convert it to DXT, then send it to the GPU). We have thought about GPU-based compression, but the STB compressor we are using now is very fast, and GPU compression is not as good as authors compressing ahead of time.

       When we texture page, we are swapping higher and lower _size_ images to the GPU, just as if you had turned down the texture resolution slider.

       So if you are flying forward, and there is a texture used in a landmark behind you, that texture _might_ go “cold” (e.g. it hasn’t been used in a while) and we might page the low-res version onto the GPU and throw out the high-res one to free up VRAM. When you look behind you, there is no pause – you see the low-res texture until we can page the high-res texture back into VRAM.

       If you have more VRAM than X-Plane needs for everything (e.g. you have an 8 GB card, max res, no add-ons, or you have a 4 GB card, texture slider is down 1 notch) then we won’t page anything out – there’s no point in having empty VRAM – and when you turn around to see the landmark, it’s high-res instantly.

       Note that in the FIRST case (we paged it out) this would have been a stutter or glitch in the flight in GL, and in the second case your results are no worse than they used to be in 11.41.

       1. Ben, thanks for explaining. So you are keeping all the textures (maybe in lower resolution) for all possible view directions in case the user needs it? Sound like some waste of resources. Earlier you said: “If it looks like it’s getting too close to full, shrink textures to a smaller size”. With the recent description this means you are freeing a high-res texture and add a lower-res texture instead. To me that’s texture paging, too (one texture out, another texture in). That seems to help VRAM being tight, but not performance (taking away some memory bandwidth from CPU and GPU).
          One more question, assuming I’m looking back while moving forward: Will I see textures being replaced with lower res while those textures move away from me, or will you flip roles and the textures in flight direction will be replaced with lower res then?

24. I think it is your job as coder, and probably also your very own standard, to try to optimize the new code (VRAM pager) to get to swap the textures as efficient as it is possible, but I also wonder to what degree it is above that reasonable to spend additional expensive development time in an effort to further tailor the software to low or lower end hardware?
    It may be time to call the child by its name. Many users are not willing or able to set up X-plane in a way that it runs well.
    If I understood correct, If a user observes blurry textures, that is because he/she is running out of VRAM, due to inadequate hardware resp. too high settings.
    I’m thus very much favoring your idea of having X-plane displaying a warning on screen in such case, informing the user of the situation, together with a suggestion to reduce texure size.
    Photorealistic graphics are nice, and high resolution textures are also nice, but it is the fluid motion (constant frame times without the occasional hick up) that has the greatest impact of giving the impression of actually being in the air and flying. As this seems to be exactly what the Vulcan/Metal update promises (with higher FPS as an added bonus, if ones GPU has some headroom) I’m looking forward to the Vulcan/Metal update with eager anticipation!

    1. only every other 3D game on the market and FS20 proves you dont have pick anymore you CAN have your cake and eat it now

25. Will you provide some tools to allow users to see how much VRAM each plugin/core system is using?

    1. We can’t tell how much the plugins are using – we just know a big chunk is used by all OpenGL code. We do have a VRAM profiler – we’ll have to see how useful it is to anyone outside the company.

       1. Ok, I believe it would be very valuable if the users would be able to, at the very least, see how much VRAM is used by core X-plane and plugins as a combined number. Would that be possible?

          Additionally, a clear indication of whether lack of VRAM have caused reduced resolutions of textures would also be nice.

          It would make it much easier for users to configure X-plane for as good graphics as possible, and cause less confusion and thereby irritation.

          Would it be possible for you to post some screenshots or a short video of what X-plane looks like with the blurry textures?

          1. I do not want to post a video like that. This post has already been massively misinterpreted and freaked everyone out.

             Me: if your machine is horribly overloaded and would have stuttered and then run at 3 fps because you’re out of VRAM, now it will just derez instead.
             Everyone: zOMG Vulkan is going to be blurry as @#$@#$.

             I can easily demonstrate what blurry textures _could_ look like by running the _buggy_ version of the texture pager last week on my 4 GB card. But you can see this at home – just drag the texture slider down about 3 notches and restart the sim! It looks the same.

             Our intent is to fix paging (Sidney has already made a lot of progress) so that just get the equivalent of the slider way down.

26. After reading all the comments, I think it would be useful to have “screen data output” (like the on screen FPS), that will display:
    * xplane texture usage
    * plane texture usage
    * plugins texture usage

    This might be useful for developers, but at least will provide a simple yet informative information to asses your plugin/plane textures load.

    Cheers
    Saar

27. If the textures are resized more or less dynamically and automatically, is it possible to set something to a fixed resolution?
    For example, it’s nice to have a high ground texture quality but not that important (at least for me) but it’s important to have taxiway signs at least readable.

    1. Not really – another user might really want readable taxiway signs (so he doesn’t get lost) and not care about the ground textures. We’re not going to have a texture slider for every element of the sim.

       My view is having EVERYTHING be about the same is really important for immersion – a high res texture next to a low one just looks weird – like the two elements were photoshopped together; our art team tries to keep things consistent. The exception is panel text that has to be readable, where functionality has to be the most important factor.

       1. I wondered whether “object priorities” could help: High-priority objects would be rendered in best quality, while lower-priority objects would be rendered at lower resolution, maybe even (Oh, I hear the screaming) in gray-levels (without color). The priority list could be like this:
          * essential runway lights
          * runway
          * essential signs and taxi marks
          * taxiway
          * essential airport buildings
          * landscape next to airport
          * additional scenery objects
          * clouds
          * …

          Note that I put down clouds at the lower end, because if I use X-Plane I want to fly; if I want to see detailed clouds, I’d watch some photographs like https://pixabay.com/images/search/clouds/. Of course if the system has enough rendering power, you can have everything at top resolution…

28. Good morning, my answer is trivial, I just wanted to know the release of the public beta, is this weekend? Thank you .

    1. It is not this weekend.

       1. I think people should read “days, not weeks” as “possibly within the next 13 days” which is not weeks.. 🙂

          Well I give my thoughts without knowing much about programming (like others have done as well I see)..:
          Could an improvement be an “internal working slider” help anything?
          If you could check how many times you have to choose a lower resolution, on a flight, you could measure how much VRAM the plugins “for this flight” are using, then tell Vulkan to expect a bit less ( or more) VRAM to use for X-plane itself – then make a sample now and then to check it out if it’s still the case?
          I hope that made sense.. if it’s doable might be something else 🙂

          Anyway I am much more comfortable reading this:
          “Me: if your machine is horribly overloaded and would have stuttered and then run at 3 fps because you’re out of VRAM, now it will just derez instead.
          Everyone: zOMG Vulkan is going to be blurry as @#$@#$” 😀 😀
          Please forgive us, the terrible users that are both a pleasure and a pain in the a** 😉

29. It sounds like this is in the weeds texture loading issues.
    It should Not be necessary to Reinvent the wheel for texture loading.
    It is quite disturbing this much time/effort is taken up on common tasks.
    Custom code also leads to Custom bugs.
    Blurry Vulkan textures after 3 years will Not be acceptable.
    Alarm bells already ringing.

    1. From all what I know about game programming, dynamic texture loading of this amount (might by terabytes with world-wide hires orthos) is not a common task at all. Not while maintaining fps without stuttering.
       I do not think, you know what you are talking about.
       And, as Ben now explained several times, blurry textures will only happen, if you put the texture res slider higher, than your VRAM can handle.
       Why not wait and see how the beta works, before talking about alarm bells?

       1. Here you go Amigo:

          https://github.com/SaschaWillems/Vulkan/blob/master/examples/texture/texture.cpp

          1. Doug, this isn’t really the problem we are trying to solve at all. You can see a glimpse of the level of complexity we’re at here:

             https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/pull/90

             1. Thanks for the link. I will have to read that more than once to fully appreciate what your team is doing.

             2. One thing to be said for VMA: it gives you an appreciation of the complexity of what the GL driver does and doesn’t even remind us about.

                My mental model for Vulkan is that app devs are like teenagers who have had a giant temper tantrum at the DX11/GL driver writers.

                App dev: SCREW YOU DAD! YOU CAN’T DO ANYTHING RIGHT! YOU DON’T UNDERSTAND ME! I’M GONNA GO RUN AWAY AND EVERYTHING WILL BE BETTER!

                And the driver writers are the exasperated parents who are tired of the verbal abuse.

                Driver writer: Really? Alright then. Go take care of yourself, good luck with that.

                And now we’re living in our friend’s basement eating only ramen cuz we didn’t realize that, like, cooking was a thing.

                App dev: Hi…dad…um….yeah..no no it’s going fine here on my own. Everything’s great. I was just wondering…what’s a pipeline barrier? I know the answer, I just want to see if YOU know.

                Driver writer: this is not going to be good….

             3. I think Laminar needs to go back to the drawing board.
                For ground textures, the ones closest to and surrounding the plane should be in VRAM (obviously), to render the scene.
                The next textures further away should be loaded in computer RAM.
                As the plane flies the RAM textures are brought into VRAM.
                This is obviously very quick (RAM to VRAM).
                The ground textures are never loaded DISK to VRAM – as this causes stutters and problems.
                They are loaded DISK -> RAM -> VRAM.
                The DISK to RAM loading is a separate thread in the background. It does not affect real time GPU rendering. Hence no more stutters.
                There should be a setting for MAX RAM usage. If my machine has 32 GB I could put Max RAM = 24 GB (as an example).
                Therefore, that adds up to a Significant amount of Preloaded textures ready to go.
                The algorithm only needs to figure out which textures should be in VRAM and which should be in RAM.
                As plane location is updates they go FROM RAM to VRAM (and vice versa).
                You will never see any more stutters unless the user has low specs and they put a stupid high texture setting.
                Also, this way, there should never be the horrible brown textures on the horizon. Those brown textures are allowed to be lower resolution. They should not be hard coded a fake brown color.
                If Vulkan has brown textures I will be spitting chips!!

             4. I think what you’ve described in this comment is exactly how X-Plane has worked from X-Plane 9 to 11.40.

                X-Plane has _never_ loaded textures from disk into VRAM (because you can’t, not in Vulkan, not in OpenGL) and we haven’t loaded textures on the main thread since at least going back to v9, so you never wait on disk access (or the DMA to VRAM). Those problems were solved along ago and nothing about the new proposal is going to go backward.

                What’s new is we think we can do better when VRAM is tight. If that’s not a problem because you have 8 GB, then great, the old design worked and the new one will too. But we do hear from users who have less VRAM (or more add-ons) whose systems are “pretty close” and here we think we can do better.

             5. “As the plane flies the RAM textures are brought into VRAM.
                This is obviously very quick (RAM to VRAM).”

                Not to throw shade at you, but this is an absolutely false statement. Uploading texture data takes significant amounts of times, maybe not in terms of every day human measurements, but definitely when it comes to real time applications. “Oh shit, we need this texture that is in RAM in VRAM” is absolutely not an okay strategy in any way shape or form, unless we want to go back to square one and re-introduce stuttering.

                The problem with blurry textures is way overblown here on the post, our strategy is not to reduce everything down to 1×1 pixel textures. The strategy is to downscale textures when it’s not noticable (think of a 4k texture that is either out of view, or far away and you wouldn’t ever see any of its detail in full). And when the full detail texture is needed, get that back into VRAM ASAP. We have very good insight into texture usage and which textures are needed right now and which ones aren’t, and that’s our strategy on how to do deal with overcommitted VRAM.

             6. XP has design flaws.
                There should never be any stutters or texture “emergency”.
                The plane does not fly or change direction fast enough to be an excuse.
                There should only be a grid of full high def textures, and the rest to the horizon of low res textures.
                The algorithm needs to switch out lower res textures to full high res textures.
                And vice versa (behind the plane).
                This is not rocket science. Other sims have mastered it already.
                There is ample enough time to switch textures…
                If it’s coded properly!

             7. I cannot deny that if the entire scenery system were made up of equally spaced textures in a grid, solving paging would be trivial.

                But that’s only a fraction of what the X-Plane scenery system, aircraft SDK and plugin SDK actually do.

             8. Not only that, but the underlying assumption here is that this will fit into VRAM as is. Which isn’t necessarily the case at all, so something more clever than that kind of scheme is necessary. Which brings us into this timeline.

30. Here is what I don’t understand.

    How can a GTX1080 with 8GB of memory have less VRAM stutters than a RTX2080TI with 11GB? Do OpenGL fill more data into memory the larger memory you got? Logically I would think yes, but if so does it fill up untill there’s no more space left?
    I tested 11.35 vs 11.41 and there seems to be no difference. GTX1080 seems to just have less stutters than RTX2080TI in X-Plane, verry annoying to say the least.

    1. I have no idea. Having not put a profiler on _your_ 1080 and 2080, I have no idea what specific stutters you see. There were enough things that _could_ stutter and enough black boxes in GL that it was never an option to dig into this kind of thing. Many stutters in 11.41 are _not_ VRAM related.

       1. Please email me if there is a profile that can be put on to help narrow down any potential stutter bug/cause, can be tested on default XP installation. FYI, most noticeable stutter happens during turns on ground, the image stutters the faster you turn. Same in air, when banking in a turn, more stutters the faster you turn. Almost no stutters going straight forward. Frames are above 70fps.
          PS. I do apologies for the bug report in comment field.

          1. I too have the same kind of stutters. 2080ti here.

31. This whole texture-paging algorithm looks complex enough to keep evolving beyond 11.50.
    (it is ‘cache strategy’ by another name after all)

    What testing will you be doing with ortho scenery?
    Does ZL18 ortho bust even the largest gfx card ram? (especially when flying straight until new 1×1 tiles need to be loaded)
    Will there only be 2 states per texture: 1/1 rez, and 1/8 res?
    If so, do you think that might result in a jarring mix of sharp/blury whereas all textures at an intermediate 1/2 or 1/4 rez might be more pleasing? (loaded question!)

    I think a ‘timeframe’ of how long things might be blurry would help expectations:
    Situation: flying in a straight line, then turning 180 to fly back (only then resulting in a need to page textures)
    (or in vr, just looking over your shoulder)
    Expectation: only a few frames of blurry textures as the algorithm avoids stutters while it flushes unneeded textures from the previous view, and loads the 1/1 rez textures – ie. not blurry for very long???

    And:
    ‘If you have blurry textures for a minute or more, lower your texture-quality settings down a notch’
    The right advice?

    1. There are two hard things in computer science: naming things, cache invalidation, and off-by-one errors. 🙂

       It’s worth noting that orthophoto paging _already_ exists and has been around since X-Plane 9.2 – you put a LOAD_CENTER directive on the texture giving the sim meta-data about its position in the real world and we can calculate the needed res and page it down based on distance. So this is the _easy_ case. :-). I haven’t done the math for ZL18 but you can get near-perfect LOD behavior out of orthophotos with LOAD_CENTER.

       For other textures, I expect there will be multiple states, e.g. it can be de-rezed due to pressure and de-rezed due to it being “cold” and those don’t have to be the same states. And I agree that having a wide mix of sharpness isn’t great.

       I don’t know how long the textures will take to page in…we can take measurements that mean something once the algorithm is paging the right things – if it’s not, the load times can be weird due to too few or many textures paging in the wrong order.

       1. The whole adaptive blurriness subject is fascinating – even Youtube needs to deal with it and I suspect there are Academics spending all their research time on it. I’m 62 and even when wearing my glasses things are never quite in focus and I’ve become accustomed to it. That got me to thinking that another input control for your rezing/de-rezing consideration might be something like a slider that involves 20/20 20/40 20/50 etc vision ranges for acceptable levels of blurriness. Just a thought.

       2. While we are on “hard things in computer science”: There are two methods to solve any performance problem (they say), that is hashing and caching; all other problems can be solved by an extra level of indirection 😉
          The family of “off by one” also includes numeric instability, division by zero and other amazing integer overflows.
          One of my first amazing experiences was this: “If you read 123 as real (float) and print it again, the output rarely was 123 (back in 1985); it was more like 122.9998 or 123.0001” (today it’s much better).

          1. Fun and games with real-valued expressions in Fortran DO loops… somewhere there’s probably a loop still running today 🙂

32. what i dont get why not just cut off any thing with less the 2GB of vram …. its not that far fetched most modern games min specs are at lest 3GB of vram now just put warning when some one with less then 2GB trys turn vulkan mode on that its unsupported done and move on to other things

    trying to support iGPUs and 5 year old GPUs isnt worth your time these people need to upgrade

    1. It’s poor customer service to change system requirements in a point release.

       X-Plane 12 or whatever would be a good time to bump up the specs.

    2. A meaningful portion of our revenue comes from people running integrated GPUs (flying with a mouse and keyboard, no less). People coming to flight simming from the aviation side (rather than gaming) tend to start there and buy a better PC later.

       1. Actually I was quite disappointed by the performance increase replacing the Intel-iGPU with an AMD Graphics card with 4GB VRAM: The increase in frame rate was marginal, even though in principle the card should have significantly more rendering units. So iGPUs may actually do unless you add a really powerful GPU.

          1. The lack of a boost may be due to driver overhead – you’ll definitely want to re-eval the win with Vulkan.

33. Hi,

    you said Vulkan/Metal would be the big next level xxx performance improvement.

    Now you say the texture quality is less quality than actual and reflections would be first stage total off.

    So why do i need Vulkan/Metal if i get the same result actual with turning the sliders down ?

    Blurry textures…oh my good…

    As i write above for me the visible texture quality is already less than 2 years ago.

    I don’t know what you do with Vulkan/Metal but i was expecting more FPS, more texture quality, more visual effects and less stutters…

    And now we get blurry textures with steady 30 FPS instead of 60 FPS and good texture quality ???

    ” I am on 6 years with X-Plane and every tweak i done in case of the hole weather stuff decide if you have stutters/more FPS or not. Fact. If i take the default clouds for example i get horrible stutters. 3 layers of clouds, bad weather and the FPS are not playable. For me there is the POINT to work on. And we get rid of all problems ! ”
    Also a hint is to implement blending a forest mesh at higher ALT instead of XXXthousands of trees.

    SystemSpecs: I7-8700k @ 5.3 GHZ cropped 8AUER (Bios: MultiThread disabled) CPUZ SingleCoreBench @625Points, 8GB GCARD@2200MHZ, 4K Toschiba 55’INCH, 32GB-HYPERX RAM, 2x 1TB SAMSUNG_EVO_SSD, SAITEK PRO FLIGHT YOKE and QUADRANT.

    Finally critic/complain/ideas at a high level as always.

    Greets
    X-PILOT

    1. You’re overblowing this way out of proportion before you’ve even seen the update. As someone on an 8gb card, you’ll be absolutly fine. The techniques Ben is describing here is widely used in the AAA game industry moreso than you realise (Take a look at Red Dead Redemption 2 for example when it first boots up. Blurry textures untill it has established a stable vram target… then works to constantly downsize textures that you barely see.) Granted the art direction could be better, but XP still does an ok job of trying to keep up with the sheer amount of art assets and size (both 1st and 3rd party).

       The tldr, lets calm down a bit and see how your system is affected.

34. Hi Ben,

    I’m still a little confused on all the benefits of 11.50 Metal on Mac. will this really just solve the stutter issue (which is awesome) or might we also get increased fps and or ability to move graphics sliders up without noticing negative drops?

    thanks

    1. On the Mac if you are limited by your CPU, Metal will be _much faster_.

       1. How do i Get the Beta 11.50

          1. Just pray

35. Developer starts post with:
    “One thing I have learned during my time here in the matrix is that users often find new bugs to be significantly more annoying than existing ones; trading an existing bug for a new one is often seen as a big step backward, even if the new bug isn’t that bad. I think this is just human nature – we get used to things – it’s what humans do – and this takes the sting off of some bugs that have been around a while.”

    Users comment:
    “These blurry textures (that we haven’t seen yet) are so annoying!!! That is a huge step backwards! Let us decide to have the stutters again.”
    “Vulkan is @&#%…”
    “Devs are @&#%…”
    “Go to DirectX and drop Macs/Linux!”
    “I have a small GPU, I’m scared!”
    “I have a big GPU, drop small GPUs!”
    “100 years of Vulkan port and now that!”

    1. 🙂 🙂 🙂

    2. Funniest comment ever !
       I’m still laughing and falling off my chair every time I read it !
       🙂

    3. if a 1050 is a big GPU to you im not sure your in the right hobby
       i said drop igpus and gpus with less then 2GB of vram you can get 1050 or = gpu with 4GB now for 140 bucks
       imo there is zero reason to keep letting these people limp on they can keep using OpenGL for now or use Vulkan but know that there limited VRAM is going mean they have deal with less then perfect textures

    4. Best way to mute those voices is to throw some beta at them, making abstract complaints concrete ones 😉

36. Hi, Ben!
    I am a plugin developer (on openGL). Could you explain what I have to do to be ready for the Vulcan to come? Will it break openGL plugins?

    1. I’ll address that in detail in a separate future post shortly. If you need guidance sooner, please contact dev-rel.

37. Hi Ben, great respect for your efforts over the years to make X-Plane better and better. VATSIM has now announced that it will ask the development teams of VATSIM clients (XSB, swift) to insert codes that will automatically disconnect when the FPS falls below 20. A major disadvantage for many x-plane users. Because sometimes the frame rate drops quickly when you approach a complex scenery. You cannot predict what the FPS will be at airport XY, nor the necessary rendering options. Will Vulcan / Metal in 11.50 help improve this situation?

    1. It can help, in that it can get you more FPS. But also turning down the rendering settings and not running X-plane near the limit of the hardware can help too.

       1. Is this possible to do dynamically? There is a nice plugin called 3jFPS that adapts view distance, cloud quality, anti-aliasing and scenery shadows to help raise fps . But it cannot lower enough things to make flying into say NY or Boston run decent fps unless i use low setting so start with. Then im getting 60 fps en route but with less detail than i could be getting at 30fps which i would be happy with.

          I can get 30-40 fps everywhere else with high/max settings, even on final to airports in less populated areas.

          I could just change the settings every flight based on the dep/arr airports, but again, that doesnt address enroute. Maybe the adaptive ‘blurring’ in 11.50 will help with this? Although I think how much texture is loaded in system memory (texture quality setting) is the big factor for me anyways.. and i dont think the blurring effects that?

          1. It’s not easy to do dynamically because (1) when FPS falls we don’t necessarily know which slider will bring it back and (2) some controls don’t take effect immediately or have heavy reload costs.

             The adaptive textures will only help if (1) VRAM for textures is the problem and (2) you were previously running in a stuttering/low FPS/GL driver failing scenario.

             1. autogen… when ever im trying to get a large FPS boots first thing i do is alway drop autogen back step

                for what ever reason the autogen is biggest hit the frame rate next is AA which is why i keep pressing for new faster AA then SS, Temporal AA would HUGE to have as it doesnt use as much GPU and looks way better then FXAA

                please once you get Vulkan in look at adding some new AA modes

             2. Sure it’s not easy to it dynamically, but a little lua script does it quit well. At least I use it all the time.

             3. I made that plugin Lamont referred to a few years ago. The main function of it is to slowly and smoothly adapt
                /private/controls/reno/LOD_bias_rat
                to the current (average) framerate.
                That worked surprisingly well.

                Now, ahem, I am concerned the plugin will undermine the logic which textures to compress/decompress/page etc. in 11.50 and you get reports on blurry-bugs caused by the plugin in the end.

                I have no idea how much this can be a problem and if the plugin will lead to noticeable blurry textures where they would not have appeared without it. I’ll test it as soon as the beta is out.

                BTW, I have put a big red disclaimer about 2 years ago on top of the download page on the .org, that the plugin uses undocumented private DRs and there is no guarantee at all it will work with future versions. But, in some rare (ahem again) cases, a few users might have over-read or forgot about it… Some of those may also forget to disable their plugins and re-test before sending bug reports to you (and not to me), I’m afraid.

                I will try to communicate this on the .org of course.

             4. I appreciate your being up-front re: the compatibility expectations … and that’s all we can really ask. The intent of the art controls is to allow people to tinker but there’s not attempt at compatibility.

                My expectation is that hacking the LOD bias (which is not insane) will probably still work in 11.50 and won’t hurt the texture paging – an object is in the working set or it’s not, but we consider how long it’s been “cold” in paging it out.

                Other stuff definitely won’t work – like, one third party dev told me he couldn’t change the shadow map sizes with DRE. True!! A lot of configuration can now ONLY be changed at certain times during load, so that we can _preload_ the new shaders, settings, allocate VRAM, etc. We used to check every frame for config changes and update on the fly, but that’s a recipe for stutters. So those settings now have to be hacked in settings.txt.

             5. The texture pager is designed to “just work”, it runs continuously in the background and attempts to do a best job effort. If you increase or decrease the LOD dynamically, it might have to load/unload textures, but the whole system is already designed to cope with this. I have a sim install with a bunch of third party stuff, including your script (and FlyAgi’s script attempting to do similar things. Although not running concurrently, of course). From what I can tell, the texture pager and your script co-exist very happily on that install.

             6. Many thx for your responses Ben and Sidney.

                “…the texture pager and your script co-exist very happily on that install…”

                Then I’m as happy as my plugin on a dev’s machine (and somewhat relieved) to hear that. : )

                Cheers, Jörn

       2. In XSB 2.0 it will disconnect if the frame rate does not recover in a reasonable amount of time but a momentary drop in FPS should not result in your connection being disconnected if it recovers and remains stable. Doing as Ben says is correct and sensible. Air craft that fly slower than real time in virtual world are problematic to other pilots and ATC.

38. If DDS files now need to be pre-compressed. What format for compression is best?

    1. Hi Paul,

       They _do not need_ to be pre-compressed! That was not a requirement in 11.40 and it is not a requirement in 11.50. There will be no compatibility problems because aircraft or scenery with PNGs stop working. With that in mind, they _should_ be compressed. We have been recommending this for years now – it was a good idea before and it still is.

       Sorry, that wasn’t what you asked, but I wanted to address it because “we’re removing the uncompressed max res texture slider” has been mis-interpreted as “pre-compression is now required”, and I wanted to nip that one in the bud. What format is best? If you mean, which of DXT1/3/5 should I use for my material, I think the answer is: DXT1 if you don’t need alpha, DXT5 if you do — between DXT3 and DXT5 your mileage may vary but we’ve had good luck with 5 as a sane default.

       1. Thanks. When I convert png files to dtx1/5 they show up in my orthos as a DDS file. Is this right. Sorry for all of the dumb questions but I am trying to follow your blog and be ready for vulcan. We have many students scheduled and do not want delays.

          1. The questions aren’t dumb – the original post is confusing. But you don’t _have_ to do this to be ready. It’s a nice-to-have. Basically yeah, you want a DDS file where you used to have a PNG. You can leave the PNGs side-by-side or remove them, your choice.

39. So, is today the day?

    1. When it’s done it’s done.

Comments are closed.