I meant to post this weeks ago, and basically just lost track of it, so thanks for the reminders in the comment sections.  Here is a PDF export of our slide deck from FSExpo.

Flight Sim Expo 2018 Slide Deck

There is professionally shot video of the event, but it wasn’t shot by us, and I’m afraid I have no idea when it will be posted. We’re looking into using our own cameras next year so that we can ensure a video post on a more timely basis.

 

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

24 comments on “FlightSimExpo 2018 Slide Deck”

  1. Thanks so much for sharing, that was a great read. You guys are so funny.
    -A Patient X-Plane User.

    NOT! Where’s Vulkan already!?!?!? 😀

  2. Thanks, Ben. Have to admit, in over 10 years as an X-Plane user and developer, FSExpo and the chance to meet you gents was quite the experience. X-Plane is life! 😉

  3. Thanks for that.
    Could you please confirm what the dark and light blue bars in the performance slide for Vulkan mean? Is that a performance comparison between OpenGL and Vulkan, in fps, for your standard performance test?
    If yes, omg, it’s reasonable to expect circa 100% performance increase? Very impressive.

    1. The dark bar is the number of OpenGL API calls made to draw that frame in Airfoil-Maker; the light bar is the number of API calls made in Vulkan.

      Since it’s call count and not CPU time, it is _not_ directly convertible to a FPS boost. Furthermore, the structure of a pure UI frame from Airfoil-Maker (suing the v10-and-older UI kit) is not even remotely comparable to the rendering engine. So the predictive power here for FPS in Vulkan vs GL in the final sim is about zero.

      We only showed it because we thought it was a good illustration of one of the results of a huge philosophy difference between Vulkan and OpenGL:

      – Vulkan places a large emphasis on pre-initializing persistent API objects that describe things you will want to do during drawing. These initializations are meant to be done ahead of time.
      – Therefore the actual work to to draw a Vulkan frame is relatively small – it’s just “remember those things I made? Go use them!” So the frame itself is fewer API calls (because there’s less information to specify) and less actual work to be done by the CPU (because a lot of the work has been done ahead of time and saved).

      1. First of all, thanks for the reply 🙂

        Did you mean to say the dark bar is Vulkan, the light bar is OpenGL? Because the light bar seems to require about twice as many API calls.

        Wait, now I’m getting confused. So the number of API calls is increasing with X-Plane’s new versions? And you do mention in the presentation a roughly 25% performance boost with v11.30. Could you provide clarity?

        Pre-initializing things has been a performance “trick” in software development for decades 🙂 In university I heard this story of a crazy who would build huge tables of cosine, sine, tangent values, that would be used in his application. His application would take more time to load then the apps from others, obviously, but it was blazing fast to use.

        Cheers, looking forward!

        1. Nnnnnno…the dark bar is OpenGL, and OpenGL, the old API, is clearly taking way more API calls – about 17k GL calls vs 5k Vulkan calls.

          1. I see the problem now, we are talking about different slides 🙂

            The slide I’m talking about is 3 slides after the one you are talking about, it is showing bars per each major XP11 version, and they are growing. It seems to indicate average fps. It is immediately before the slide “what about my addons?”

            Cheers.

          2. That slide is -just- showing FPS test performance, so it’s all OpenGL, just by version. 11.30 has some optimizations that came as part of restructuring that make things faster.

          3. OH..wait, I see now. BOTH sets of bars are OpenGL – they’re just running different fps tests. I don’t remember which ones they are since it’s been a few months, but my guess is dark blue is probably test 5 with the 747 and light blue is test 3 or 4 with .. .not the 747? So it’s all OpenGL, it’s all controlled by version, just different rendering loads.

          4. Bruno’s talking about the second bar-chart, with XP versions along the X, and what has to be fps on the Y axis, titled ‘Performance’ – is this the FPS of Planemaker?

            On performance and new assets, I never see any conversation about LOD’s for objects – I understand XP supports different meshes for different LOD’s. Because – ‘trees’. I’ve never found the story behind why trees are locked down and … immutable! A support-FPS-nightmare or a technical reason?

          5. The tree engine doesn’t use the same code path as OBJs. Since trees have way fewer vertices, each tree is not an individual object/instance – that’s not an efficient path. So since they’re not OBJ-like they’re not getting LOD swaps. (At 8 vertices a tree, cutting to less in an LOD isn’t a win.)

          6. I was more hoping of a way to *add* vertices – these perpendicular cardboard cut-outs would be the next thing that lets down that close-up ground experience of GA airports.

      2. This comment makes me wonder what the impact on X-Plane load time might be with Vulkan when we get that far along. Not that it matters after you get into the sim.

        1. Don’t panic – the things being loaded were cheap enough to be sent to the GPU _per frame_ at current speeds (e.g. 30-60 fps) in today’s sim, so it’s not going to kill load times. It’s just going to be less work in the subsequent frames.

  4. Great!! thank you for the pdf!

    I’m a helicopter fan, and I don’t see many helicopter friendly features. One that’s most annoying for me is the throttle in the S-76 (governor for helicopters) that moves the fuel control lever… this should be done by some other dataref instead of throttle ones. maybe introduce FCU or other datarefs?

    Waiting for the next beta release!! I really like messing with betas 😀

    1. I don’t understand what the issue is here with the datarefs…throttle has always controlled fuel in helicopter in X-Plane because the collective is a separate control. What use case do you have where this matters?

      1. Hello Ben!,
        Thank you for your reply.

        The real lever doesn’t move by the action of the governor, like in the S-76, so additional coding have to be done in order to make it behave realistically. I think by default there should be a dataref for the lever manual fuel control and another daref for the fuel injected controlled by the governor/FCU (fuel control unit)/FADEC. Or more info in the Planemaker manual 😀 .
        I’m trying to do the AS-365 N2/3 (have all the manuals for it) and I find it hard to do it just with default datarefs without coding (I’m rookie coding).

        PS: English isn’t my language I hope you can understand what I mean.

  7. I have the impression that the whole thing is somewhat too much biased towards graphics: Do your really have time for a close-up look at the scenery while flying? For some ego-shooter it may be more important, but I personally feel that smooth framerate and accurate simulation of systems is more important than than having some reflection in a window of some terminal building (for example).
    I understand that you are freaks and you want to get everything out of the machine that you can get out of it. Also what surprised me is “The dark bar is the number of OpenGL API calls made to draw that frame in Airfoil-Maker; the light bar is the number of API calls made in Vulkan.”:
    Why are you comparing 3D power for an application that does no 3D at all (Airfoil-Maker). My very old ATI Mach64 could also draw an impressive number of 2D-lines per second unter X11, but todays applications are typically not drawing 2D lines.
    Why don’t you compare the frame-rate killer that is like “50% transparent clouds with sun reflections and shadows on clouds, body, and panel?
    One thing I wonder (if you have the graphics power): The visualization of the flight model did not change much since X-Plane 8; is the current flight model and particle system flexible enough to show a “virtual wind channel” with particles following the flow of air around the body and wings? Basically the idea is that the particles flowing from the front (let’s say) are deflected by the forces that the flight model computes at specific locations (mostly wing sections)…

    1. As I said before and in the talk, the slide compares the number of API calls to accomplish basic drawing tasks between the two APIs to illustrate how much less per-draw setup there is in Vulkan, where things are more prebuilt and direct. The test is in Airfoil-Maker because that’s the app that runs correctly in both right now.

      A comparison of GPU power used for 3-d clouds would be totally meaningless. 3-d clouds are bottlenecked on ROP blending, which is a hardware resource. That’s good for comparisons between GPUs but won’t change at all between GL and Vulkan.

  8. Hi!

    I have a little doubt.
    I dont have much money to purchase a top pc, so… Vulkan will improve to increase
    FPS number in game?
    (a little?)

Comments are closed.