shadertools: Resolve dependencies in ShaderInputs

[felixpalmer]

For visgl/deck.gl#8782 implemented on 9.0 branch and tested against deck. Works for project/project32 pair. Also tested with luma.gl/examples/showcase/instancing which uses a non-ShaderModule input

Change List

• Obtain module dependencies when constructing ShaderInputs
• Uncouple getDependencyGraph from ShaderModuleInstance type
• Test

[felixpalmer]

@ibgreen In general I don't see have we can resolve the types on the module dependencies, so I have at least made it so the user can specify the expected props on creation:

const shaderInputs = new ShaderInputs<{
  custom: CustomProps;
  picking: typeof picking.props;
}>({custom}); // <- No need to pass `picking` at runtime as it is a dependency of `custom`

shaderInputs.setProps({
  custom: {color: [255, 0, 0]},
  picking: {highlightedObjectColor: [1, 2, 3]}
}); // <- setProps has correct type that knows about `picking`

[ibgreen]

A problem here is that if a ShaderModule has been involved in instantiation, all its dependencies have been converted to ShaderModuleInstances. So I am not convinced that the result of any repeated calls to resolveModules() will actually be a ShaderModule[] in spite of this typing effort.

The ShaderModule / ShaderModuleInstance dichotomy seems to generate a lot more trouble than it is worth.

I note that instantiation actually doesn't do that much, it adds some methods (that could be global functions) and initializes some things for perf:

    this.deprecations = this._parseDeprecationDefinitions(deprecations);
    this.injections = normalizeInjections(inject);
    if (uniformPropTypes) {
      this.uniforms = makePropValidators(uniformPropTypes);
    }
}

Perhaps we should try to move away from ShaderModuleInstance.

[ibgreen]

I will try to remove ShaderModuleInstance so that we can avoid this mess, partial work in #2074 will continue tomorrow

[felixpalmer]

Sounds good, it also makes it simpler for situations where we extend ShaderModule, like ShaderPass. Why have ShaderModuleInstance, but not ShaderPassInstance? If I instantiateModules with ShaderPass instances what is returned etc...

[ibgreen]

@felixpalmer Just an update as I am still working on the PR to remove shader modules #2074 it is getting pretty big. As long as we are not planning to backport this it should be fine.

[felixpalmer]

@ibgreen thanks for the push. Types aside, is the implementation OK to land in v9.0? I would like to land visgl/deck.gl#8782 and continue to port the other shader module. I'm happy to work with full ShaderModules as you suggested