Replace Linux I/O implementation with io_uring functions

[AwayB]

Describe the project you are working on

3D game with a city containing many buildings, rooms and streets

Describe the problem or limitation you are having in your project

I wish to create a (possibly randomly generated) large city world with multiple streets, a few hundred buildings, and thousands of apartments/rooms in my game. This is difficult to do without cutting the world in parts and having load times, for example every time we change streets or enter a building.

Dynamically loading floors of buildings would work, but that solution also leads to possible lag while Godot loads what is necessary.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

io_uring is a recent I/O library that is specific to Linux but is sure to gain traction and rise in every field that requires massive I/O work such as databases or games needing a large amount of things to load.

It makes I/O non-blocking and fast, very fast actually, pretty much pushing the SSDs to provide all of the speed that they can.

With the current prices for SSDs, even premium ones, going continuously down, and the speeds going up (Samsung's 980 Pro and WD's SN850 are premium models that both boast 7Gb/s of reading speeds), a library like io_uring can be the cornerstone on which dynamically loading elements becomes possible for the entirety of a game. In other words, a complete disappearance of load times.

This is a feature that I believe most games will simply want in the coming years. Sony also boasted of the disappearance of load times for the PS5, and the trend will keep going stronger. I think it would be a great selling argument for Godot to be an engine that has no load times.

While I imagine that a fully dynamic loading system is going to be difficult to make, the first step towards it in my opinion is to integrate io_uring as the main library to load elements into Godot.

This isn't an immediate thing, most people don't have M2 SSDs that run at 3.5Gb/s or 7Gb/s yet, but there is no doubt that it will come. I believe that evaluating the impact of using io_uring for all I/O operations and the cost of transferring to it right now is something that will be very valuable to Godot in the near future.

Besides the impact in speed and game comfort, fast non-blocking I/O will become in the next 10 years the defining feature between an "old software" which loaded everything and the "new software" where the dynamic loading removes any sense of lag/slowdown, even on startup. Software, including games, will more or less load instantly someday, and even though that is far away, I think we should evaluate the impact of shifting towards this model as soon as possible.

Also, because the change towards asynchronous I/O will be so drastic, I believe that even though io_uring is currently Linux-only, it will no doubt make its equivalent in Windows and most if not all other OSes over time. Godot will IMO gain a lot by looking into integrating io_uring as soon as possible.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

All I/O operations, opening, reading, etc, should be replaced with their io_uring equivalent. Possibly the networking features of Godot might also want to have a look at it.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It would rewrite the very core functions of opening and reading files, and loading them. Not something you'd want in a script.

Is there a reason why this should be core and not an add-on in the asset library?

Opening and reading data is core.

[Calinou]

a library like io_uring can be the cornerstone on which dynamically loading elements becomes possible for the entirety of a game. In other words, a complete disappearance of load times.

Unfortunately, uploading textures to the GPU (even VRAM-compressed) will ensure this does not happen in practice. GPU bandwidth can be a bottleneck, and CPUs are still easily saturated while loading large textures.

Implementing texture streaming will likely result in a greater positive impact on load times and avoiding stuttering during gameplay. It will also work on all platforms, not just Linux. io_uring is also only present since Linux 5.1, which means a fallback would need to be provided for old LTS Linux distributions such as CentOS. I'm not sure if such a fallback can be provided at run-time either.

[AwayB]

Unfortunately, uploading textures to the GPU (even VRAM-compressed) will ensure this does not happen in practice. GPU bandwidth can be a bottleneck, and CPUs are still easily saturated while loading large textures.

Of course GPU and CPU will remain bottlenecks, for now anyway.

Implementing texture streaming will likely result in a greater positive impact on load times and avoiding stuttering during gameplay. It will also work on all platforms, not just Linux. io_uring is also only present since Linux 5.1, which means a fallback would need to be provided for old LTS Linux distributions such as CentOS. I'm not sure if such a fallback can be provided at run-time either.

Yes, it's not an immediate concern, and texture streaming is more immediately gainful. I just think that the implications of using io_uring should be evaluated for the long run. It is sure to become the standard, and even if GPU/CPU bottlenecking will be there, it's only going to diminish. Entirely removing the HDD bottleneck is probably a good thing for that mid-term (say, 2 to 5 years) milestone where most people who game will shift almost exclusively to SSDs.

[AwayB]

Windows copied I mean built an equivalent called IOring.
https://docs.microsoft.com/en-us/windows/win32/api/ioringapi/
It is very recent (July 2021 I believe) but should run off the same principles as io_uring, so Godot could implement both at the same time in the future.

Adding this for reference:
https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/
https://windows-internals.com/ioring-vs-io_uring-a-comparison-of-windows-and-linux-implementations/