From 739134d6f5f2a6df875bd711c72590c5523dfdab Mon Sep 17 00:00:00 2001 From: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com> Date: Fri, 13 Nov 2020 07:50:09 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20=20@=20e261b?= =?UTF-8?q?88a7304091b07ae0ced6ddac088e91dc8b5=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/print.html | 3 ++- book/rfcs/001-resource-binding-syntax.html | 3 ++- book/searchindex.js | 2 +- book/searchindex.json | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/book/print.html b/book/print.html index b907f8b1d3..f1ad57c74c 100644 --- a/book/print.html +++ b/book/print.html @@ -419,7 +419,7 @@ fn main(inputs: &ShadingInputs, indirect_lighting: &IndirectLighting) { }

Suggestion

-

I think the most ergonomic and future proof binding method would be to have descriptors in structs, bound to the entrypoint. This allows us some nice, even more ergonomic upsides later on (when support is more widely available) where we can put data members in these structs as well. And along wit this, we can have very egonomic CPU side code as well, where we can keep shader invocation looking like a function call for a large part, instead of having to manually bind to slots again.

+

I think the most ergonomic and future proof binding method would be to have descriptors in structs, bound to the entrypoint. This allows us some nice, even more ergonomic upsides later on (when support is more widely available) where we can put data members in these structs as well. And along with this, we can have very egonomic CPU side code as well, where we can keep shader invocation looking like a function call for a large part, instead of having to manually bind to slots again.

Prior art

Metal

@@ -477,6 +477,7 @@ fn compute(compute: Compute, buffer: Buffer<N0, N0, RuntimeArray<f32>&g }
+