Skip to content

Conversation

@nnethercote
Copy link
Collaborator

@nnethercote nnethercote commented Nov 19, 2025

The Guide is very inconsistent on some matters of style: capitalization, use of backticks, and some word choices. Like a fine layer of grit over all the surfaces of a workshop, these low-level irritants get in the way of larger, more important changes. Let's fix them all now.

@nnethercote nnethercote changed the title Improve the Guide Improve the Guide's consistency of style Nov 19, 2025
@nnethercote nnethercote requested a review from LegNeato November 19, 2025 06:09
@nnethercote
Copy link
Collaborator Author

I fixed one more inconsistent capitalization case (nvidia/NVidia -> NVIDIA).

Copy link
Contributor

@LegNeato LegNeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just need to decide if we use code backtics for crate names. I think that is common practice and looks better but open for discussion.

A couple of particular rust features make writing CUDA code much easier: RAII and Results.
In `cust` everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which
A couple of particular Rust features make writing CUDA code much easier: RAII and Results.
In cust everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In cust everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which
In `cust` everything uses RAII (through `Drop` impls) to manage freeing memory and returning handles, which

This should probably be code due to being a crate name? Not sure. Woul be good to link it too.


Instead of an unreliable system of macros, we can leverage rust results for this. In cust we return special `CudaResult<T>`
results that can be bubbled up using rust's `?` operator, or, similar to `CUDA_SAFE_CALL` can be unwrapped or expected if
Instead of an unreliable system of macros, we can leverage Rust results for this. In cust we return special `CudaResult<T>`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Instead of an unreliable system of macros, we can leverage Rust results for this. In cust we return special `CudaResult<T>`
Instead of an unreliable system of macros, we can leverage Rust results for this. In `cust` we return special `CudaResult<T>`

# Getting started

This section covers how to get started writing GPU crates with `cuda_std` and `cuda_builder`.
This section covers how to get started writing GPU crates with cuda_std and cuda_builder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, these are crate names which are usually marked as code?

Suggested change
This section covers how to get started writing GPU crates with cuda_std and cuda_builder.
This section covers how to get started writing GPU crates with `cuda_std` and `cuda_builder`.

```

Where `XX` is the latest version of `cuda_std`.
Where `XX` is the latest version of cuda_std.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Where `XX` is the latest version of cuda_std.
Where `XX` is the latest version of `cuda_std`.

```

Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, `rustc_codegen_nvvm` guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).
Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, rustc_codegen_nvvm guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, rustc_codegen_nvvm guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).
Finally, if you would like to use types such as slices or arrays inside of GPU kernels you must allow `improper_cytypes_definitions` either on the whole crate or the individual GPU kernels. This is because on the CPU, such types are not guaranteed to be passed a certain way, so they should not be used in `extern "C"` functions (which is what kernels are implicitly declared as). However, `rustc_codegen_nvvm` guarantees the way in which things like structs, slices, and arrays are passed. See [Kernel ABI](./kernel_abi.md).

A little shorter and clearer.
The Guide is currently very inconsistent with capitalization of
abbreviations.

The general trend is towards lower-case for informal English, but for
formal English (such as documentation) I think upper-case is still
preferable.

- gpu -> GPU
- cuda/Cuda -> CUDA
- rustacuda -> RustaCUDA
- llvm -> LLVM
- nvvm -> NVVM
- ir -> IR
- ptx -> PTX
- libnvvm -> libNVVM
- Optix/optix -> OptiX
- SPIRV -> SPIR-V
- cuBlas/cuRand -> cuBLAS/cuRAND
- i (the pronoun!) -> I
- TLDR -> TL;DR
A lot of names are used sometimes with backticks, sometimes without.
This commit removes backticks where necessary for these:

- rustc
- rust-gpu (which will become "Rust GPU" in a subsequent commit)

And adds backticks where necessary for these:

- rustc_codegen_*
- cuda_builder
- cuda_std
- lib.rs
- Rustc -> rustc (truly!)
- rust -> Rust
- NVidia/nvidia -> NVIDIA
[I accidentally squashed two commits, and can't be bothered separating
them.]

The existing text uses "codegen" frequently as a shorthand for "codegen
backend". I found this confusing and distracting. ("Codegens" is even
worse.) This commit replaces these uses with "codegen backend" (or
occasionally something else more appropriate).

The commit preserves the use of "codegen" for the act of code generation,
e.g. "during codegen we do XYZ", because that's more standard.

Also, currently headings are a mix of sentence case ("The quick brown
fox") and title case ("The Quick Brown Fox"). Title case is extremely
formal, so sentence case feels more natural here.
@nnethercote
Copy link
Collaborator Author

Ok, I have updated to use backticks on crate names like cust, cuda_std, and rustc_codegen_*.

@nnethercote nnethercote requested a review from LegNeato November 21, 2025 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants