Skip to content

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

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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