It has been almost a month since my last post on Vulkan and the state of development; a lot has happened since then, both for laminar research and the world.
First, at this point, no one working for laminar research has COVID-19. We have people working on X-Plane in at least six countries, including northern Italy. The team News on Slack as of Tuesday was that everyone is in some degree of lockdown and/or voluntary social distancing, varying by country. Schools in the US are temporarily closed, so both Chris and I have the kids at home.
Being sequestered at home has not affected our internal pace of development because our entire team is distributed and works at home; we have no office to close. This work-at-home pattern started almost twenty years ago when Austin had people like me working on part-time contracts to modify specific parts of the sim - it never made sense to relocate people to South Carolina and open up an office. Being remote also lets us hire people anywhere in the world who have the unique blend of skills we're looking for.
At this point we haven't seen any operational issues either; mostly running our business requires that our devs have internet and electricity and that the data centers we use for our cloud servers remain open and operational.
So in summary, we are very fortunate that the new coronavirus is not affecting our development and operations; other industries are paying a high price to stop the spread early. We have several things we are working on right now, and this spring is a critical time in our development schedule.
Vulkan And Metal
Update: I have gone in and changed Vulkan to Vulkan/Metal in a bunch of places - Mac users were confused as to whether we had silently dropped support for Metal at the last minute – we have not!
We are posting developer preview nine to our private testers today; hopefully this will be the last private build before a public beta candidate. We acknowledge we're reaching public beta much later than we had hoped/wished/anticipated, but we are now aiming for a public Vulkan/Metal beta by the end of March. If you are already rolling your eyes at a public beta date that is less than two weeks away, I don't blame you; having been this late, it's on us to post the beta to show progress. With that in mind, I am going to describe what we’ve been doing for the last three months and why it has taken so long to get here.
The Vulkan/Metal public beta is several months later than we had anticipated because of "scope growth" – that's manager nerd speak for "we added more stuff to it than we originally planned." Scope growth (adding more features/code/tricks than you originally planned) is one of the big ways that projects miss original deadlines, so the big question is: what did you add and why did you add it?
The first thing we added was better handling of plugin drawing. The rewritten plugin compatibility layer provides better drawing compatibility for more plugins, including weather plugins on Windows. We went with the rewrite mostly because of the level of bugginess we saw with third party add-ons in the early developer previews.
Plugin drawing was definitely a case where we learned how to do a better job from the first version of the feature (plugin compatibility that went into the first private beta); if we had received that second-generation design via time machine we probably could have shipped faster. Adding weather support was pure feature creep–a new thing we didn't plan on, but something that we thought was worth extra schedule time.
The second thing we added was better handling of texture paging. Once again, this was a feature where we had to rewrite the feature (multiple times in fact!) based on the feedback we got from our testers to really come up with something solid.
Our first generation texture paging around the first private developer preview was very simple: most stuff lived in VRAM, with a little bit of code to move unused stuff out of VRAM. It was a minimalist strategy that let us develop the rest of the sim and worked great on high-end cards. It was clear from day one that it wouldn’t be good enough for public beta.
Our second generation strategy added automatic movement of texture res up and down with VRAM pressure and code to page out textures that weren’t being used. This shipped about half way through the private beta, and was better, but suffered from one fatal flaw: as you turn your head, the stuff behind you isn't being used. Under heavy memory pressure users would constantly turn their head and see blurry textures that would then "res up". The results were distracting and unacceptable quality-wise.
We now have finished our third generation strategy: besides automatic texture res control based on VRAM pressure, we now set the relative resolution of non-orthophoto textures by distance to the aircraft. A background task on another core "crawls" the scenery near your aircraft and reevaluates the texture res of nearby scenery constantly, effectively transferring VRAM to where it is needed most. This process is completely transparent; authors do not need to modify scenery in any way for it to work, and since it runs on another core (as does the paging), it does not affect frame rate.