Skip to content

Kernel extensions

Steven Johnson edited this page Feb 7, 2019 · 23 revisions

TODO: possible additional arguments to graphics.defineEffect and their motivation, constraints, etc.

TODO: some ways to interact with already-loaded shaders, e.g.

  • replace the source (non-binary shaders)
  • dummy it out ("removing" the shader)
  • updating uniforms array if available

Elaborate what all of the above needs to observe. The source-affecting options are mainly throwing a bone to shader editors, so maybe these should be opt-in only... would it make sense to invalidate other options such as category, time dependence, etc.? (I'm thinking any such shader is potentially already making use of the configuration in question, so this would pull the rug out from under it; whereas with the source alone there's less danger.)


Rough outline of maximal form, this being stuff in kernel declaration:

timeTransform = "sin", timeArg1 = 5, timeArg2 = 3,

for CoronaTotalTime stuff,

wantsUniformVectors = true, resolveUniformVectorCount = true,

for uniform arrays,

isEditable = true,

for shaders that can be rewritten,

fillSamplerType1 = "cubemap", fillSamplerType2 = "volume",

for sampler types. Some instancing stuff would go here too. Anything else?

(Compute kernels might be a parallel but similar thing?)

Most of these would produce a "shader state" object that can be used to effect these operations, obtainable from some graphics API for example.


Priority-wise, this is mixed, but I think at the moment everything is related to another idea anyhow.