diff --git a/docs/user_guides/templates/wgcore/buffers_initialization.mdx b/docs/user_guides/templates/wgcore/buffers_initialization.mdx index 8e36da3..83ed726 100644 --- a/docs/user_guides/templates/wgcore/buffers_initialization.mdx +++ b/docs/user_guides/templates/wgcore/buffers_initialization.mdx @@ -34,7 +34,7 @@ If you can’t derive `bytemuck::Pod` for your own type, consider the [solution it can be passed to `GpuScalar::init`. - Any type implementing `AsRef<[T]>` (like `Vec`, `&[T]`, or `DVector` from [`nalgebra`](https://nalgebra.rs) can be passed to `GpuVector::init`. -- Any matrix type, parametrized by `T`, from the [`nalgebra`](https://nalgebra.rs) crate can +- Any matrix type, parameterized by `T`, from the [`nalgebra`](https://nalgebra.rs) crate can be passed to `GpuMatrix::init`. ```rust @@ -68,7 +68,7 @@ instead by calling the `::encase` constructor of `GpuScalar/GpuVector/GpuMatrix` it can be passed to `GpuScalar::encase`. - Any type implementing `AsRef<[T]>` (like `Vec`, `&[T]`, or `DVector` from [`nalgebra`](https://nalgebra.rs) can be passed to `GpuVector::encase`. -- Any matrix type, parametrized by `T`, from the [`nalgebra`](https://nalgebra.rs) crate can +- Any matrix type, parameterized by `T`, from the [`nalgebra`](https://nalgebra.rs) crate can be passed to `GpuMatrix::encase`. diff --git a/docs/user_guides/templates/wgcore/buffers_readback.mdx b/docs/user_guides/templates/wgcore/buffers_readback.mdx index dea313f..1669173 100644 --- a/docs/user_guides/templates/wgcore/buffers_readback.mdx +++ b/docs/user_guides/templates/wgcore/buffers_readback.mdx @@ -15,7 +15,7 @@ The code described in this section can be run from the ::: After our buffer have been [initialized](./buffers_initialization.mdx), and our compute kernels have run, you might need -to read the results back to RAM for further processing on the CPU side. Reading the content of a GPU buffers require a +to read the results back to RAM for further processing on the CPU side. Reading the content of a GPU buffer require a few steps: 1. Be sure that the buffer you want to read from was initialized with `BufferUsages::COPY_SRC`: ```rust diff --git a/docs/user_guides/templates/wgcore/hot_reloading.mdx b/docs/user_guides/templates/wgcore/hot_reloading.mdx index d3f9d89..445d827 100644 --- a/docs/user_guides/templates/wgcore/hot_reloading.mdx +++ b/docs/user_guides/templates/wgcore/hot_reloading.mdx @@ -45,7 +45,7 @@ Say you are working on an application’s code (like, for example, one of the ex [wgebra](https://github.com/dimforge/wgmath)) using a [cargo patch](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html). Using the code snippet from the previous section, you can leverage hot-reloading on **any** shader, even the ones from the local dependencies. The `derive(Shader)` macros will automatically figure out the absolute path of all the -shaders at compile-time so the can be watched with `Shader::watch_sources`. +shaders at compile-time so they can be watched with `Shader::watch_sources`. :::danger This automatic detection of shader paths might not work properly if you run your application from a directory that is @@ -53,8 +53,8 @@ different from the root of the rust workspace it is built from. This is due to s that will hopefully be stabilized in future versions of the compiler. ::: -This won’t work for shaders of a dependency that is not available locally on your machine, since there is no way to -actual shader file that could be modified (since they are embedded in the library directly). In order to make it work +This won’t work for shaders of a dependency that is not available locally on your machine, since there is no way that +the actual shader file could be modified (since they are embedded in the library directly). In order to make it work for these shaders, you can [overwrite them](./overwriting_shaders.mdx) with a local version of the shader by specifying their path with `Shader::set_wgsl_path`. After their path is overwritten, `Shader::watch_sources` needs to be called and hot-reloading will work. diff --git a/docs/user_guides/templates/wgcore/shaders_composition.mdx b/docs/user_guides/templates/wgcore/shaders_composition.mdx index 901e61d..3070829 100644 --- a/docs/user_guides/templates/wgcore/shaders_composition.mdx +++ b/docs/user_guides/templates/wgcore/shaders_composition.mdx @@ -14,7 +14,7 @@ The code described in this section can be run from the [end of this page](#complete-example). ::: -The main feature of `wgcore` is the provide the ability share and compose WGSL shaders easily across crates. Roughly +The main feature of `wgcore` is the provide the ability to share and compose WGSL shaders easily across crates. Roughly speaking, `wgcore` exposes a trait and derive macro for generating the boilerplate needed by [`naga-oil`](https://crates.io/crates/naga_oil) for shader composition. @@ -26,7 +26,7 @@ since it’s a regular rust `struct`, it can be exported and used across crates Say you have two `.wgsl` shaders, one `dependency.wgsl` exposing a wgsl structure and a mathematical function, and the other `kernel.wgsl` defines a compute pipeline entrypoint that calls functions from `dependency.wgsl`. The dependency shader -contains a nana-oil `#define_import_path` statement indicating it is intended to be imported from other shaders. The +contains a naga-oil `#define_import_path` statement indicating it is intended to be imported from other shaders. The kernel shaders contains an `#import` statement indicating it requires symbols exported by the dependency shader: