fix: Ensure VertexBufferLayout matches parsed WGSL shader @location layout

[Kaapp]

For deck.gl tracker, and to fix issue raised in visgl/deck.gl#9531

Background

When I originally ported the pointcloud layer, the attribute struct had been set up like the following:

struct Attributes {
  @builtin(instance_index) instanceIndex : u32,
  @builtin(vertex_index) vertexIndex : u32,
  @location(0) positions: vec3<f32>,
  @location(1) instanceNormals: vec3<f32>,
  @location(2) instanceColors: vec4<f32>,
  @location(3) instancePositions: vec3<f32>,
  @location(4) instancePositions64Low: vec3<f32>,
  @location(5) instancePickingColors: vec3<f32>
};

which results, perhaps confusingly, in the following error, as instanceColors are provided as a unorm8x4 and should have stride 4, not 24.

If, instead, that struct is ordered in the following way (note: instancePositions have been moved down), it works as expected:

struct Attributes {
  @builtin(instance_index) instanceIndex : u32,
  @builtin(vertex_index) vertexIndex : u32,
  @location(0) positions: vec3<f32>,
  @location(1) instancePositions: vec3<f32>,
  @location(2) instancePositions64Low: vec3<f32>,
  @location(3) instanceNormals: vec3<f32>,
  @location(4) instanceColors: vec4<f32>,
  @location(5) instancePickingColors: vec3<f32>
};

After some digging, it turns out that error is being thrown because the VertexBufferLayout we pass to the WebGPURenderPipeline contained a different order of attributes than those being bound to the shader by setVertexBuffer. In some cases that generates this error. In other cases, where the buffer sizes all match it subtly binds the buffers with data meant for other buffers. In my case, I got 'lucky' that I re-ordered the buffers into the same order as they were specified by deck's AttributeManager.

Instead, ensure that we produce a VertexBufferLayout that matches the order of the attributes from the WGSL source code by sorting the bufferLayout. This means that both WGSL samples work as expected.