Entertaining explanation of OGL vs Vulkan for flight sims

  • Now I understand why IPACS was working on Vulkan support last year ... this guy was entertaining to listen to for 20 minutes 8)

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    • Official Post

    As far as I know Aerofly FS 2 compiles shaders on OpenGL ahead of time and also loads textures in the background ahead of time (as much as possible) and we did this from day one afaik (designed with these limitations in mind). Vulkan now just enforces what we've pretty much already been doing but gives us even more control to do it correctly. :)

  • The video, while enthusiastically presented, is simplified to the point of being misleading.

    The main take away is that the Vulkan driver doesn't do as much and instead relies on the application side to prepare resources for rendering. There are also efficiencies by design with the new interface to scale better with more CPUs and more dynamic scenery. Also importantly, the per draw overhead is significantly reduced for large scene / entity count scaling.

    The down side is that the application need perform some of the tasks previously taken care of automatically, so if care is not taken, performance can be worse. To assist with this, example code has been made available.

    As Jet-Pack suggests, an OpenGL application can perform well if it manages resources more carefully even though it may not have as much control. Experienced studios have been doing all the things he categorizes in the Vulcan pattern for the last two decades.

  • GregDude has summarised this well. Unfortunately with each new technology there is a lot of hype and misinformation, especially when it comes to what can be gained in terms of performance. The NVIDIA OpenGL driver was always extremely well optimised, as you can see when you perform some comparisons Vulkan <-> OpenGL. On the other hand the AMD OpenGL driver was always a bad to say the least. With Vulkan extra work was put on the client programmer which in our eyes makes development for smaller teams a lot more difficult. Getting Vulkan right on various platforms is extremely complicated and time consuming.

    Vulkan, Metal and OpenGL are just API's used to communicate with the GPU, but the real performance improvements for software comes when the programmers understand where time is spent and lost on the GPU, which is not solved by simply switching from OpenGL to Vulkan.

  • They're a funny bunch, but I like them :)


    And whatever they have done has done wonders for XP. First beta is a huge performance improvement, especially in VR.

    Now, if AF2 could have ground and air traffic, real weather, ATC... :)

    (I still love AF2 in VR, but XP is getting close, plus has all the other stuff)

  • ...

    Vulkan, Metal and OpenGL are just API's used to communicate with the GPU, but the real performance improvements for software comes when the programmers understand where time is spent and lost on the GPU, which is not solved by simply switching from OpenGL to Vulkan.

    This is why initially, video game programmers tried to stay away from explicit APIs. They already had something that worked and did not wat to invest the effort and resources to understand how their renderer works. On most video games, the first implementations were basically wrappers (doing the equivalents of old gl or dx calls with minimum effort) which were usually disasterous, delivering the existing performance at most while also bringing in bugs. So it seemed that it's a high-risk low-reward thing, which otherwise could always be solved by telling the user the buy more powerful hardware.

    This is perfectly normal human gut reaction: I want to make a game, not understanding how the computer running it, works.

    Using an explicit APi is also a good way to identify CPU-side bottlenecks, because OpenGL (or DX11) is black box where we put out wishes in and somewhere, sometime, something, will happen. It does not know why we are issuing a sequence of wishes thus it tries to guess what we wanted (that can result in e.g. re-compiling shaders between two frames) and we also don't know for sure if e.g. our operations will commence in the order we put it in.

    If we want it to succeed, we have to give it our main thread to make sure it can work and wait without blocking anything else.

    There is a minecraft clone on github which was done via OpenGL, interestingly, all in plain ANSI C language (no C++). It took me a while to read it and understand what's happening on the OpenGL side.

    Then I realized there's a devbranch forking off of it, the same minecraft clone but on Vulkan.

    It's a perfect demonstration how badly I had no idea what the OpenGL calls tried to do in the black box.

    BUT! After I have understood what I have to do/re-do for each single frame, these patterns were starting to re-appear in all other Vulkan demo codes and projects I was taking a look at! ^^

    Best Regards

    Balazs

    Ryzen 2700X, HyperX 32GB, 2060 Super 8GB, win10/ubuntu19

    Saitek X52 HOTAS, Logitech G920 pedals

    freetrack/opentrack
    X-Plane 11, DCS modules: A-10C, Ka-50, FC3, Mirage 2000C, F/A-18C, Persian Gulf

  • Flying an IFR route makes the upfront predictive work easier but with VR, where users like to do more sightseeing, predicting becomes much harder 8)

    Well, prediction does not happen about what you would like to draw, but rather how and when. Nevertheless, speed comes handy when you have to render twice as many images than you used to be. ^^ It's also important to assess if stuff is covered by other stuff and discarding it as early as possible.

    Best Regards

    Balazs

    Ryzen 2700X, HyperX 32GB, 2060 Super 8GB, win10/ubuntu19

    Saitek X52 HOTAS, Logitech G920 pedals

    freetrack/opentrack
    X-Plane 11, DCS modules: A-10C, Ka-50, FC3, Mirage 2000C, F/A-18C, Persian Gulf