What's going on with my software development focus
One of the first question marks I left in a notebook was concerning the source of a "pool of threads" where a distributed computing model would from-draw. The context was in game development for an eventually-correct multiplayer simulation where there was no centralized server AND imperfect information sharing between connected computers. Regardless of hardware caps the main concern was that any data stored in memory would be interrogable by the host, meaning: if one player received an asyncronous update for another player's changes but the consequences of that change would by the game's rules not yet be visible to the greater environment, that update could be preperceived by the legal cracking of one's own device memory.
At the bare minimum any delayed messages would still need to be processed by some resource on the rendering machine in time for the results that SHOULD be shown perfectly, but that consistency did not need to be necessarily lived in the accessible components for that player so long as the computation could be verified once it reached the surface and the states synced. This implied a non-player cloud before general cloud was a thing, as well as a precedent for blockchain mining protocols dictating a software-level distribution of unidirectional compute sharding...at the base level though the effects of taking in batches of data at the same time as running an intensive gaming application would create an undesireable experience for both the CPU and the user as dynamic memory pressure inevitably leads to inefficient cases of object creation at runtime...
While I've done some GPU programming in the past, it is with the advent of "general purpose" GPU availabilities that I have found the ultimate answer to "pool of threads" in contexts including and beyond game development. My working title for this answer is GP2, where I focus on the most stable and vendor-unlocked avenues for non-graphics related code architecture and tooling. For the last decade I've been tackling the web platform with the foreknowledge that eventually other OS platforms would devolve into mere shells for HTML + JavaScript and with the release of WebGPU I am calling that deevolution complete!
The Modules So Far, Introducing GP2 for the Web
GP2 Store is the primary module linking the GPU concepts of shaders, buffers and bindings to an agnostic management engine. While everything in the browser is required to be written in JavaScript at the time of this writing, the object of a Store is to bring everything into a data space in a way that can be compared and persisted. Because WebGPU is opinionatedly low- level and has several redundancies from a conceptual viewpoint the Store provides an API which blends most of what can be 1-to-1'd while still maintaining the raw connections to GPU land in order to attempt restartable/failproof consistency in case of a connection loss at worst or replication across devices where instantiation order of resources would matter most.
GP2 Shader is a compromise between the intentional limitations on WGSL and the requirements of dynamic code execution. RAM is more than a number, it is a method of access for a runtime that needs to switch focus and at the GPU level there exists well-defined strata of memory availability the optimizations for which cannot be deterministically compiled for without a planner that can pre-orchestrate between dispatches and workgroup caches. Depending on the reported capabilities of devices different logic must be constructed to achieve the same execution results - and while WebGPU provides the surface for that reporting and execution the experimentation of this tool suite revealed several gaps where greater flexibility could be co- erced within the generic framework without losing the performance benefits of offloading of compute operations to GPU land.
Inversion of Control Principles (Running CPU from GPU)
Currently (and correctly) all stateless operations require a stateful launchpad. Any shader or other GPU-based program runs at the behest of a traditional computer's dispatch. A graphics card has no clock by which to time itself except as a count of threads which have been completed within a pass. Therefore, GP2 takes up the task of establishing a configureable back- feed of command from the runner to the dispatcher/orchestrator. Imagine a shader requesting that another shader run with- out having knowledge of the WebGPU platform but having knowledge of some piece of function not contained in its source and the ability to communicate that some chunk of result is ready to be passed as buffers to that next section of outside code.
Test-driven capabilities for a linkage protocol
"I need a module that responds with res X to req Y" is a high-level request-style test assertion that GP2 posits will exist as a way for sub-components to extend asks to a motherboard without requiring vendor-specific headers (but allowing 4 them)