Render API v3

[parasyte]

This ticket will track exploration to improve the render API further. This is a superset of #107

First up: Refactor the render API to follow the middleware pattern. This API replaces the CommandEncoder and TextureView references with a single RenderPass ref.

I'm not able to get this to work with closures, so the new API will force the caller to manage the swap chain, command encoder, and render pass. This design isn't in the spirit of pixels, which wants to minimize user responsibility over the GPU.

I also had trouble reusing the RenderPass for both pixels and the custom-shader example, as described by the Encapsulating Graphics Work article. The custom shader samples from a texture that is written by the pixels render pipeline. I have not found a way to make this work with a single render pass, but some quick searching indicates that Vulkan has a concept of subpasses for this (and I cannot find any mention of this concept in webgpu).

Even if subpasses were implicit, the pixel that the fragment shader works on would need to be inout, which is apparently not valid at global scope. I wasn't even able to create a render pass with multiple color attachments (hoping the first pass would use the first attachment, the second pass uses the second attachment) but that didn't work because the render pipeline needs to know about all attachments! I must be missing something because deferred rendering doesn't appear to be possible at all.

[parasyte]

The shadow example creates one render pass for each light source and another for the forward rendering pass. A total of 3 render passes per frame. The water example also uses three render passes. This doesn't appear to align with the recommendations in the linked middleware article:

The goal of this api is to use a fewest possible render passes as possible. Reducing render passes is a very important for lower end hardware. These GPUs use a method called "tiled rendering" where there is significant cost to ending a render pass.

It may be that there is just no way to do these rendering techniques without multiple render passes. Which would extend to the pixels design with post processing as separate render passes. And because the current render API does satisfy this design, I think that optimizing it any more is unnecessary.

I will still keep this tracking ticket open, just in case things change in the future, or if new ideas happen to come up. Previous discussions suggested it may be nice to allow users to manage the GPU and treat pixels as just a piece of middleware. I no longer see that being the case with the render API accepting an arbitrary render pass (as described in the linked article) but I can still imagine a world where the application wants to own the wgpu resources (especially Device and Queue) but will allow pixels to borrow them. This I think is still on the table.

[parasyte]

Here's talk of render subpasses in webgpu: gpuweb/gpuweb#393 This is something that the noise renderer in the custom shader example could make use of. But I still don't believe this will be usable in general cases. Taking the shadow and water examples again as illustration.