Skip to content

consider pulling 'access' into the type of a pointer/reference #1604

@dneto0

Description

@dneto0

From discussion at #1569 (comment)

Instead of

  [[block]] struct B { count:  i32 };
  [[group(0), binding(0)]] var<storage> mybuf :  [[access(read)]] B;

  fn main() {
      let p: ptr<storage,i32> = &(B.count); 
      let count_copy = *p; // valid
      *p = 12;   // not valid by tracing back to the variable.
  }

Do this?

  [[block]] struct B { count:  i32 };
  [[group(0), binding(0)]] var<storage,read> mybuf : B;

  fn main() {
      let p: ptr<storage,read,i32> = &(B.count); 
      let count_copy = *p; // valid by type checking that the read is from a read ref.
      *p = 12;   // not valid, by type check because the LHS has type ref<storage,read,i32>
  }

One consideration is what happens at function boundaries.

In the original case, I would argue that the 'read' attribute should be required on the declaration of the formal parameter. (Note: In Vulkan SPIR-V passing pointers to storage buffers is only permitted with an extension that turns on VariablePointers or VariablePointersStorageBuffer.) There might be some accommodation where a pointer to read_write buffer might be passable into a read buffer pointer formal parameter. That would be TBD.

In the second case, the default rule is no accommodation like this, and no automatic conversion of a read-write pointer to a read-only pointer. Alternately, add a constructor (conversion) builtin that has the effect of changing the type.

cc: @kvark

Metadata

Metadata

Assignees

No one assigned

    Labels

    wgslWebGPU Shading Language Issues

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions