René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`loadPixels` and `PGraphics` dependency batching in WebGPU","articleBody":"The processing API allows performing arbitrary GPU-\u003eCPU readback on demand via the `loadPixels` method. This is generally an extension of the immediate mode philosophy of processing but poses significant friction with modern graphics architectures. In contrast with opengl, which goes to significant lengths to preserve the illusion that GPU data is easily accessible, WebGPU is designed to foreground that GPU operations are asynchronous relative to the CPU timeline. While the API does support blocking on these operations, the expectation of most framework including `bevy` is that you won't.\n\nConcretely why this matters is because modern graphics libraries really want to batch rendering together for efficiency reasons. For example, in Bevy, all cameras (which could be considered an analog to a `PGraphics` instance) want to render at the same time every frame. `loadPixels` introduces an architectural complication in that the current draw state may need to be flushed and made visible to any other graphics context at any arbitrary time.\n\nIn other words, beyond any performance concerns, this highlights a potential dependency problem between `PGraphics` instances: \n- In the event where multiple `PGraphics` instances aren't dependent on each other, batching works fine and we can delay flushing all their draw state til the end of frame. \n- When a `PGraphics` is used in another `PGraphics`, e.g. an off-screen texture used by something in rendering to the screen, we could simply just track a relative order to ensure the Bevy `Camera` for one runs before the other.\n- If the user calls `loadPixels`, we need to flush the draw state right now and make the texture visible to potentially any other CPU code.\n\n## Approach for WebGPU with Bevy\n\n We should start just by mirroring the immediate mode API. What this means is that we'll mirror the `drawStart`, `flush`, `drawEnd` lifecycle. Set `CameraOutputMode::Skip`at the beginning of each frame for each surface to render only to the intermediate texture and `CameraOutputMode::Write` only when calling `drawEnd`.\n\nWe can handle `loadPixels` in this way just by doing a synchronous readback after a `flush`. It's fine, and will superficially look like opengl's behavior from the user perspective.\n\nBecause this immediate mode approach likely has some undesirable overhead (although tbd, it may be pretty minimal), we can do our own dependency/dirty tracking if necessary down the line. What this would look like is keeping an in-flight dependency graph of `PGraphics` and how they're being used, and only trigger flushes when they *acutally* need to be made visible to other graphics contexts. This isn't hard to do but will make the implementation more confusing.","author":{"url":"https://github.com/tychedelia","@type":"Person","name":"tychedelia"},"datePublished":"2025-11-07T23:44:15.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/1320/processing4/issues/1320"}