feature: WebGPU Rendering Enhancements#256
Conversation
…ain (to bring it into connectomics quickly...) experimental, might try typeGPU again
…sformer plugin...
…, to compare it with the type-gpu version
…with the webGPU stuff (startlight cant build wgpu-utils, site/ cant resolve webGPU types)
… node-dependencies...
thinking through how to make better use of how webGPU works with regard to the nice way of thinking via REGL.
Jarbuckle
changed the title
Jarbuckle
changed the title
|
|
||
| import type { Declaration } from "./declarations"; | ||
|
|
||
| export class WGSLShader { |
There was a problem hiding this comment.
still reading through all this - so far I like a lot of it!
my first thought here though is that I dont think this being a class is helpful!
why not type WGSLShader = Declaration[] ?
There was a problem hiding this comment.
It all comes down to preference, I guess 😅 I like to think of shaders (in their final form) as a definite thing, not just raw data.
| } | ||
|
|
||
| serialize(): string { | ||
| return JSON.stringify(this.#definition); |
There was a problem hiding this comment.
if this class was instead an open type - then its users could do their own serialization in whatever form they wanted
There was a problem hiding this comment.
True, but they could also extend the class and override the functions that way. Again, I think it all comes down to expectations and mental models; there is no functional difference, in my mind, between the model you're proposing and the one in the code currently.
| this.#definition = { declarations }; | ||
| } | ||
|
|
||
| static deserialize(serialized: string): WGSLShader { |
There was a problem hiding this comment.
this is just asking for runtime errors imho
There was a problem hiding this comment.
Curious which runtime errors you're thinking are most likely? Deserialization failures? Or issues with the shader not being a valid shader? Or something else?
| } | ||
|
|
||
| asSource(): string { | ||
| return this.#definition.declarations.map((d) => d.__gen()).join(';\n'); |
There was a problem hiding this comment.
this is the only useful part of this class - could easily be
function asWgslSource(declaration[]) { ... }
There was a problem hiding this comment.
True; personally, I prefer the .asSource() call, since to me at least it presents a clearer entity model for my mental map of the interface.
| highlightValue: number; | ||
| } & QuantitativeFilterRanges; | ||
|
|
||
| export const applyCamera = func( |
There was a problem hiding this comment.
I like a bunch of the other constructed wrappers, but I'm not so sure about the func constructor. it feels less ergonomic then just the literal wgsl string you'd use - and because its internal to a shader, its not really buying us much in terms of type safety is it? functions defined this way still get invoked in raw WGSL
There was a problem hiding this comment.
I'm not saying get rid of it - but what if Declaration had an escape hatch member type to allow a literal blob of WGSL?
There was a problem hiding this comment.
Does it need to be internal to a shader, though? 🤔 The goal behind this was to provide a way of making function declarations reusable across shaders; allowing for a simple "chunk of WGSL" approach feels much less encapsulated (and I do love me some encapsulation, since it sets expectations -- crucial for the programmer-program interface, in my mind).
| vsOutputStruct, | ||
| uniform('unis', uniformStruct.name, 0, 0), | ||
| texture(categoricalTable, 'texture_2d<f32>', 0, 1), | ||
| texture(gradientTable, 'texture_2d<f32>', 0, 2), |
There was a problem hiding this comment.
this part I do like - its clear to see the structure of the things in the 'header' of the shader are generated, and because the gross part of constructing them is done elsewhere, this is a nice concise reading of the interface to the shader from outside.
| rangeParameter, | ||
| within, | ||
| constant('clip', /*wgsl*/ `array<vec2f,4>(vec2f(1, -1), vec2f(1, 1), vec2f(-1, -1), vec2f(-1, 1))`), | ||
| vertexEntry( |
There was a problem hiding this comment.
here again - I think the preamble to the vertex main fn in raw wgsl is much more legible than this:
@vertex fn vmain(v:Vertex)->VsOutput
There was a problem hiding this comment.
With that, I do agree. Part of the lack of legibility is due to Oxfmt's default formatting rules (insisting on having parameters on separate lines -- not really helping in this case), but yes, it's more readable in raw WGSL.
|
|
||
| export function param( | ||
| name: string, | ||
| type: string, |
There was a problem hiding this comment.
might be nice to constrain this more - perhaps (if its a structDeclaration) we could pull the .name out so the person authoring these doesnt have to
There was a problem hiding this comment.
Yeah, having the type be able to specifically reference a previously-defined struct would be a nice addition, agreed.
| }; | ||
| } | ||
|
|
||
| export function member(name: string, type: string, attributes?: VariableOrValueAttribute[]): StructMemberDeclaration { |
There was a problem hiding this comment.
because the type parameter here is just a raw string, and I dont have syntax highlighting because I'm not writing raw WGSL , I feel like this is a step backward in type-safeness, right?
There was a problem hiding this comment.
It is, for sure. Per my response above, making this able to handle pre-defined types seems like a definite improvement.
2 participants
feature: WebGPU Rendering Enhancements
What
In support of the Connectomics initiative, we are making updates to Vis to enable WebGPU rendering -- initially for the Scatterbrain package, but not limited to that package. WebGPU rendering will allow us to render to multiple canvases, as well as situating Vis for long-term support of modern web technologies.
This PR is focused on building reusable systems to simplify the process of defining and using WebGPU rendering pipelines. It will be an ongoing draft PR until we have settled on the systems that we want (R&D process).
How
PR Checklist
main?