shithub: gpufswip

--- a/gpufs.txt

+++ b/gpufs.txt

@@ -13,15 +13,15 @@

.AB

 Many modern computer systems have dedicated hardware for computing graphics and other floating point-heavy operations.

 GPU manufacturers and organizations try to standardize interfaces, often providing standard APIs and drivers for their specific hardware.

-This WIP paper tries to describe a potential filesystem for Plan 9 for dedicated GPU hardware.

+This WIP paper describes a potential filesystem for Plan 9 for dedicated GPU hardware.

.AE

]]]

 # Graphics or not graphics?

-GPU hardware evolved from very specialized pipelines for 2D rendering to 3D rendering and more generic interfaces.

+GPU hardware evolved from very specialized pipelines for 2D rendering to more complex 3D calculations and more generic interfaces.

 In the last few years GPU manufacturers started to sell ``unified shaders'' that allow even more generic computing pipelines.

-The trend towards hardware accelerated AI computation and the recent trend to more specialized graphics processing¹ justifies to drop native graphics processing support, at least in an initial implementation.

+Hardware accelerated AI computation and more specialized graphics processing pipelines¹ justify dropping native graphics processing support, at least in an initial implementation of a GPU filesystem for Plan 9.

 [[[ms

.FS

@@ -30,25 +30,24 @@

.FE

]]]

-This allows us to ignore many graphics-specific parts of the API, as well as potential drivers.

+This generic use of GPUs allows us to ignore many graphics-specific parts of the API, as well as potential drivers.

 Of course it also makes our interface a non-standard interface, but due to the nature of Plan 9 filesystems this should be fine.

 # The implementation

-Since driver development is hard and it's hard to get reference implementations for common GPU drivers, this first implementation will be fully CPU based.

+Since most GPU drivers are very complex and it takes a long time to develop them, this first implementation will be fully CPU based, using an interpreter engine to run the shaders.

 The interfaces however should look as similar as possible to a potential GPU implementation.

 Due to the nature of filesystems, this should make it easy to ``upgrade'' applications to actual GPU hardware: Using a different GPU filesystem is all that's needed.

 The software itself doesn't need to change.

-Furthermore, since real drivers are a rarity, this makes software that relies on the GPU filesystem work on systems that don't have dedicated graphics.

+Since real drivers are a rarity, this implementation approach also makes software that relies on the GPU filesystem work on systems that don't have dedicated graphics.

 Obviously, there'll be a huge speed difference in this case.

 # The filesystem interface

 This implementation will provide a very simple interface that's based on existing APIs, mostly OpenGL and Vulkan.

-Due to this simplicity and the fact that I still have a lot to learn about GPUs, the interface is not set in stone, and many details are missing.

+Because of this simplicity the interface is not set in stone and many details are missing.

 In fact, the proposed interface might not work at all with real hardware, but it can be a start.

 The shader language is SPIR-V, which is used in Vulkan as an intermediate language.

@@ -57,7 +56,7 @@

 Buffers are represented as files within the filesystem.

 This gives us the flexibility to access the buffer contents by standard file IO.

-Management and control is handled via a console like interface as a control file.

+Management is handled via a console like interface as a control file.

 Using this interface, it is possible to initialize new shaders and allocate new buffers, as well as control binding and program execution.

 For debugging purposes, an additional

 [[[ms

@@ -66,9 +65,9 @@

 file is used to display all shader and buffer bindings.

 Shaders and buffers are represented as the general concept of ``objects''.

-Each object has it's own subdirectory within the GPU filesystem (1).

-After initializing a new shader or buffer using the control file we can read back the ID of the object.

-With that, our application can know which object directory to access.

+Each object has its own subdirectory within the GPU filesystem (1).

+After initializing a new shader or buffer using the control file the client can read back the ID of the object.

+With that, the application knows which object directory to access.

 [[[ms

 .DS B

@@ -85,7 +84,7 @@

.DE

]]]

-Shaders and buffers can be loaded by writing to their files, readback is as simple as it sounds (2).

+Shaders and buffers can be loaded by writing to their files; the application can also read their contents (2).

 [[[ms

 .DS B

@@ -122,16 +121,16 @@

 # Binding shaders and buffers

-Shaders and buffers need to be bound in some way to enable shaders to access the buffers.

+Shaders and buffers need to be bound in some way that enable shaders to access the right buffers.

 It's hard to understand all the requirements of the actual hardware without diving deep into GPU architecture and existing APIs. [desc]

 Our implementation provides a very simple abstraction that is based on Vulkan and the concept of ‥descriptor pools‥ and ‥descriptor sets‥ with their bindings.

-Ideally, the same abstraction can be used for GPU hardware.

+Ideally, the same abstraction may be used for GPU hardware.

 Each shader is bound to a descriptor pool.

-A descriptor pool can describe many descriptor sets, which in turn hold the buffer bindings.

+A descriptor pool can describe many descriptor sets, which in turn point to the buffers.

-While shaders are bound to a full descriptor pool, buffers are bound to a single slot within a descriptor set.

+While shaders are bound to a full descriptor pool, buffers are bound to a single binding slot within a descriptor set.

 Shaders have everything needed to access a specific buffer compiled in their code.

 They know the set and binding of the buffer they want to access.

@@ -194,14 +193,14 @@

 Furthermore, there are bugs to be expected. [gpufs]

 There's a rudimentary SPIR-V assembler as well as a SPIR-V disassembler.

-Both are far from feature complete according to the SPIR-V specification, missing instructions can be added easily.

+Both are far from feature-complete according to the SPIR-V specification, missing instructions may be added easily.

-It is planned to build the embedded SPIR-V compiler as soon as possible, as well as the runtime engine, so we can finally run shaders and use the filesystem as intended.

+I plan to build the embedded SPIR-V compiler as soon as possible, as well as the runtime engine, so we can finally run shaders and use the filesystem as intended.

-Due to the lack of actual GPU hardware support I don't expect much performance gain compared to other implementations with the same logic.

+Due to the lack of actual GPU hardware support, I don't expect much performance gain compared to other implementations with the same logic.

 However, the interface is generic enough to allow applications to use different GPU implementations: GPU hardware, CPU hardware (single or multi threaded), network scenarios.

-It makes sense to think about future integrations into devdraw: the GPU filesystem could control actual images of devdraw and enable faster draw times for graphics rendering.

+It makes sense to think about future integrations into devdraw. The GPU filesystem could control actual images of devdraw and enable faster draw times for graphics rendering.

 Since SPIR-V is very low-level, it also makes sense to develop shader compilers for higher level languages like GLSL or HLSL.

 Applications are developed by different people and for different reasons, so those compilers should not be part of the specific filesystem implementations.