shithub: gpufswip

--- a/gpufs.txt

+++ b/gpufs.txt

@@ -41,7 +41,7 @@

 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.

-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.

+Since real GPU drivers for uncommon operating systems 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

@@ -119,6 +119,8 @@

.DE

]]]

+It will also be necessary to specify the workgroup size when executing the shader. [wkgrp]

 # Binding shaders and buffers

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

@@ -197,6 +199,9 @@

 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.

+To properly test the interface, it makes sense to implement the filesystem as a kernel device in Drawterm.

+This way we can use existing drivers and APIs on other operating systems.

 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.

@@ -235,5 +240,10 @@

 vulkan tutorial, ``Descriptor pool and sets'',

 .CW https://vulkan-tutorial.com/Uniform_buffers/

 .CW Descriptor_pool_and_sets ,

+2024.

+.IP "[wkgrp]" 10

+.ad l

+vulkan tutorial, ``Compute Shader—Compute space'',

+.CW https://vulkan-tutorial.com/Compute_Shader ,

 2024.

]]]