It has been almost a month since my last post on Vulkan and thestate of development; a lot has happened since then, both for LaminarResearch and the world.
First, at this point, no one working for Laminar Research hasCOVID-19. We have people working on X-Plane in at least six countries,including northern Italy. The team news on Slack as of Tuesday wasthat everyone is in some degree of lockdown and/or voluntary socialdistancing, varying by country. Schools in the US are temporarilyclosed, so both Chris and I have the kids at home.
Being sequestered at home has not affected our internal pace ofdevelopment because our entire team is distributed and works at home;we have no office to close. This work-at-home pattern started almosttwenty years ago when Austin had people like me working on part-timecontracts to modify specific parts of the sim - it never made sense torelocate people to South Carolina and open up an office. Being remotealso lets us hire people anywhere in the world who have the uniqueblend of skills we're looking for.
At this point we haven't seen any operational issues either; mostlyrunning our business requires that our devs have internet andelectricity and that the data centers we use for our cloud serversremain open and operational.
So in summary, we are very fortunate that the new coronavirus isnot affecting our development and operations; other industries arepaying a high price to stop the spread early. We have several thingswe are working on right now, and this spring is a critical time in ourdevelopment schedule.
Vulkan And Metal
Update: I have gone in and changed Vulkan to Vulkan/Metal in abunch of places - Mac users were confused as to whether we hadsilently dropped support for Metal at the last minute â€“ we havenot!
We are posting developer preview nine to our private testers today;hopefully this will be the last private build before a public betacandidate. We acknowledge we're reaching public beta much later thanwe had hoped/wished/anticipated, but we are now aiming for a publicVulkan/Metal beta by the end of March. If you are already rolling youreyes at a public beta date that is less than two weeks away, I don'tblame you; having been this late, it's on us to post the beta to showprogress. With that in mind, I am going to describe what weâ€™ve beendoing for the last three months and why it has taken so long to gethere.
The Vulkan/Metal public beta is several months later than we hadanticipated 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 oneof the big ways that projects miss original deadlines, so the bigquestion is: what did you add and why did you add it?
The first thing we added was better handling of plugin drawing. Therewritten plugin compatibility layer provides better drawingcompatibility for more plugins, including weather plugins onWindows. We went with the rewrite mostly because of the level ofbugginess we saw with third party add-ons in the early developerpreviews.
Plugin drawing was definitely a case where we learned how to do abetter job from the first version of the feature (plugin compatibilitythat went into the first private beta); if we had received thatsecond-generation design via time machine we probably could haveshipped faster. Adding weather support was pure feature creepâ€“a newthing we didn't plan on, but something that we thought was worth extraschedule time.
The second thing we added was better handling of texturepaging. Once again, this was a feature where we had to rewrite thefeature (multiple times in fact!) based on the feedback we got fromour testers to really come up with something solid.
Our first generation texture paging around the first privatedeveloper preview was very simple: most stuff lived in VRAM, with alittle bit of code to move unused stuff out of VRAM. It was aminimalist strategy that let us develop the rest of the sim and workedgreat on high-end cards. It was clear from day one that it wouldnâ€™t begood enough for public beta.
Our second generation strategy added automatic movement of textureres up and down with VRAM pressure and code to page out textures thatwerenâ€™t being used. This shipped about half way through the privatebeta, and was better, but suffered from one fatal flaw: as you turnyour head, the stuff behind you isn't being used. Under heavy memorypressure users would constantly turn their head and see blurrytextures that would then "res up". The results were distracting andunacceptable quality-wise.
We now have finished our third generation strategy: besidesautomatic texture res control based on VRAM pressure, we now set therelative resolution of non-orthophoto textures by distance to theaircraft. A background task on another core "crawls" the scenery nearyour aircraft and reevaluates the texture res of nearby sceneryconstantly, effectively transferring VRAM to where it is neededmost. This process is completely transparent; authors do not need tomodify scenery in any way for it to work, and since it runs on anothercore (as does the paging), it does not affect frame rate.
There are no comments to display.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now