Ferrum development journal · Part 8 of 19
Making Memory, Files, and Graphics State Agree
Adjacent allocations, runtime-loaded modules, media resources, and pipeline caching showed why a growing API surface still needs consistent state underneath it.
As more code started running, a lot of the remaining problems came from two parts of the system having different answers to the same question. Is this memory still committed? Does this file handle name the same object? Is a texture still valid when the next component uses it? Those disagreements are hard for an application to work around because the application expects the operating system to keep the answers consistent.
One memory issue involved adjacent allocations. A range could be valid across two committed regions while an older validation rule only accepted a range contained inside one region. That rule was useful as an internal simplification, but it rejected ordinary application behavior. The fix had to check complete coverage while still rejecting an actual gap.
The 32-bit runtime also continued gaining the file, network, loader, and drawing behavior used by larger application libraries. These are the details behind a familiar operation such as loading a module or drawing a small part of a game's interface. They need to agree about addresses and object lifetime even when the caller changes.
Graphics and media work had the same kind of lifetime concerns. A resource that exists on one side of a bridge isn't automatically safe to use on another side. The project investigated texture ownership and presentation rather than assuming that sharing a handle guaranteed a usable image.
Pipeline caching was another useful area of progress. The records include work on a Metal binary-archive path inside the graphics dependency, with targeted checks around serving cached pipeline work. A warm-cache benefit in those tests is useful. It doesn't mean shader stutter has disappeared from every game or that cache contents will behave correctly in every application.
For me, this stage is a reminder that adding APIs is only part of compatibility. The more important goal is a system whose answers stay consistent while an application allocates, loads, draws, waits, and releases things. Those ordinary transitions are where a lot of the difficult bugs live.
Ferrum development journal
View the journalLive19 entries so far·Updated New (19 entries updated in the last 14 days)
- Part 1Bringing FEX to macOS: The First Windows Program
- Part 2From Return Values to Pixels and Sound
- Part 3Building More of the Windows Runtime
- Part 4Following a Game Through Its Opening Video
- Part 5Installers, Saves, Fonts, and the Parts Around the Game
- Part 6Game Progress and Measuring the Right Thing
- Part 7Building the 32-Bit Graphics Path
- Part 8Making Memory, Files, and Graphics State Agree
- Part 9DirectX 12, Shader Caches, and the Steam Startup Work
- Part 10Working on Presentation and Controller Input
- Part 11A Launcher and a Freeze That Wasn't the Presenter
- Part 12Portal Reaches a Command Stream, With the Frame Still Ahead
- Part 13Correcting the Ferrum Progress Report
- Part 14Recovering the Project and Resuming Real Tests
- Part 15Making Memory Protection and Lifetime Tests More Useful
- Part 16Getting Wine's Real 32-Bit Startup to Run
- Part 17Making the Launcher Own Its Storage and Processes
- Part 18A Real Archive Roundtrip and Better File Behavior
- Part 19Asynchronous I/O and the Bytes a Cancelled Write Keeps