Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core module UBO #9040

Merged
merged 10 commits into from
Jul 24, 2024
Merged

core module UBO #9040

merged 10 commits into from
Jul 24, 2024

Conversation

felixpalmer
Copy link
Collaborator

For #8997

Change List

  • Add UBOs for ScreenPass & tidy types
  • Add UBOs for GPU transitions

@coveralls
Copy link

coveralls commented Jul 23, 2024

Coverage Status

coverage: 89.307% (+0.008%) from 89.299%
when pulling 404cc67 on felix/core-ubo
into 6f07ce0 on master.

fs: uniformBlock,
uniformTypes: {
texSize: 'vec2<f32>'
} as const satisfies UniformTypes<Required<ScreenUniformProps>>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think this double type assertion is undesirable. You said you felt it adds clarity. If it is only needed to add clarity in some cases of more "advanced usage" that is one thing. Vut if it always needs to be done I am not so sure I can feel good about it :)

Grist for the mill I suppose...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should review the ShaderModule type, the UniformsT & BindingsT generics don't seem to be that useful IMHO. I think it would be better to have the ShaderModule be generic on PropsT and UniformTypesT, as UniformsT and BindingsT can be obtained by filtering PropsT.

I've had a play and we could remove the nested const satisfies UniformTypes<..> by using the following filtering type helper:

type UniformValue = number | boolean | number[];
type FilterUniformKeys<T> = {[K in keyof T]: T[K] extends UniformValue ? K : never}[keyof T];
type UniformsOnly<T> = {[K in FilterUniformKeys<T>]: T[K]};

We then don't need the ScreenBindingProps & ScreenUniformProps types and can just do:

export const screenUniforms = {
  name: 'screen',
  fs: uniformBlock,
  uniformTypes: {
    texSize: 'vec2<f32>'
  } as const satisfies UniformTypes<UniformsOnly<ScreenProps>>
} as const satisfies ShaderModule<ScreenProps>;

Which could all be encapsulated in luma's ShaderModule definition

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that is some slick typescript.

  • You could perhaps test all this in deck by creating a compatible type or wrapper type for ShaderModule in deck.gl and once you have it working we upstream it?
  • A possible problem is to find a name that covers both "uniforms and bindings". But I suppose UniformsAndBindings is a possible choice.
  • We want to be able to explain that shader modules mapping semantic props to shader uniforms and bindings.
export type ShaderModule<
  PropsT extends Record<string, unknown> = Record<string, unknown>,
  UniformsAndBindingsT extends Record<string, UniformValue | BindingValue> = Record<string, UniformValue | BindingValue>
> = {

texSrc: TextureView;
};

type ScreenUniformProps = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really didn't anticipate this type splitting, seems like you have to go through more hoops than I anticipated. Seeing how the system is used in practice is illuminating.

@felixpalmer felixpalmer merged commit 5ce18d5 into master Jul 24, 2024
4 checks passed
@felixpalmer felixpalmer deleted the felix/core-ubo branch July 24, 2024 06:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants