[Discussion] Memory slots / swaps

[iwoplaza]

const flipPlum = wgsl.plum(0);

const makeGridBuffer = () =>
  wgsl.buffer(f32, 0)
    .$allowMutable()
    .$allowReadonly();

const gridBuffers = [makeGridBuffer(), makeGridBuffer()];

const ioSwap = wgsl.swap((get) => {
  const inIdx = get(flipPlum);
  const outIdx = 1 - inIdx;

  return {
    inGrid: gridBuffers[inIdx].asReadonly(),
    outGrid: gridBuffers[outIdx].asMutable(),
  };
}).$name('io');

const incrementFn = wgsl.fn`
  () {
    ${ioSwap.outGrid} = ${ioSwap.inGrid} + 1.0;
  }
`.$name('increment');

[iwoplaza]

@mhawryluk @reczkok What do you think of this API? 👀

[reczkok]

I think having this type of API is going to be useful. The name swap could be confusing as it sounds more like a function (which it is but I mean that I would assume it swaps something when I call it). I think creating an API that has something along the line of memorySlot and derivedMemorySlot as a separate feature could be useful. I'm not sold on that name either - I think we should separate the slots that require code recompilation and those that can be swapped using bind groups (buffers, vertex buffers, textures, etc.). bindableSlot? This would allow us to set the bindings on the pipeline level without creating separate ones for each slot variant. Then something like swap or derivedSlot could work behind the scenes by just changing bind groups and/or creating appropriate commands.

[mhawryluk]

I don't think I full get it. wgsl.swap looks like the exact same API as wgsl.plum, except we can interpolate it in wgsl.fn? when flipPlum changes do we expect incrementFn and everything that uses it to be recompiled? and if swap is supposed to just be for swapping memory buffers, than this API feels like it doesn't automate much and expect the user to define a lot of external objects, as well as most of the swapping behavior.

I'd appreciate if we could talk this through during a meeting next week.